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1.  INTRODUCTION 


1.1  OBJECTIVES  AND  APPROACH 

The  Weapon  System  phase  of  the  APL  DoD  Weapon  Systems  Software 
Management  Study  was  concerned  with  specific  applications  of  software 
design  and  management  to  major  Weapon  Systems.  The  systems  were  selected 
to  represent  a  variety  of  platforms  and  major  missions  and  to  illustrate 
all  phases  of  the  Weapon  System  life  cycle. 

The  survey  of  individual  Weapon  Systems,  as  a  major  input  to  the 
overall  APL  study,  had  the  following  objectives: 

1.  To  serve  as  a  basis  for  understanding  how  and  what  Weapon 
Systems  software  is  being  or  has  been  developed,  produced, 
deployed,  and  maintained  in  the  user  environment; 

2.  To  serve  as  a  basis  for  distinguishing  among  the  large  range 
of  uses  of  software  in  Weapon  Systems;  differences  in  func¬ 
tion,  size,  and  complexity;  and  the  way  these  differences 
affect  software  problems  and  potential  solutions; 

3.  To  provide  insight  into  the  organizational  relationships  be¬ 
tween  the  Government  Program  Managers,  system  contractors, 
software  contractors,  and  Government  test,  maintenance,  and 
training  facilities; 

A.  To  identify  design  and  management  techniques  that  have  proved 
successful  and  that  warrant  more  general  application;  and 

5.  To  obtain  opinions  from  key  personnel  concerning  ways  in 
which  the  Office  of  the  Secretary  of  Defense  (OSD)  or  the 
Services  can  contribute  to  the  improvement  of  software  cost 
and  performance. 

The  survey  of  Weapon  Systems  software  was  carried  out  through 
the  auspices  of  the  respective  Program  Managers.  System  and  software 
contractors  were  visited,  where  possible,  to  obtain  first-hand  informa¬ 
tion  on  system  characteristics  and  development  methods. 

The  selected  Airborne  Weapon  Systems  are  listed  in  Table  1-1. 

Two  other  Appendices  in  this  study  discuss  Shipborne  Systems  and  Under¬ 
sea  and  Landbased  Systems.  These  three  Appendices  present  more  detailed 
information  than  was  given  in  Section  A  of  the  main  report. 
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TABLE  1-1 

AIRBORNE  SYSTEMS  INVESTIGATED 


Weapon 

System 

Programs 

Systems 

Status 

E-2C 

Tactical  Data  System 

Deployed 

P-3C 

Airborne  Patrol  System 

Deployed 

S-3A 

Airborne  Weapon  System 

Production/ 

Deployed 

F-14 

Avionics  and  Weapon 
Delivery  System 

Deployed 

The  individual  discussions  vary  in  detail  because  of  the  differ¬ 
ing  stages  of  development  of  the  different  systems.  The  following  kinds 
of  information  were  sought: 

1.  General  System  Description:  A  sufficient  description  to  pro 
vide  understanding  of  the  overall  system  mission  and  require 
ments  and  the  operating  environment  of  the  embedded  computer 
system; 

2.  Computer  System  Architecture:  The  selection  of  computing 
equipments  and  their  operating  relationships,  including  the 
functions  allocated  to  each  computational  unit; 

3.  Computer  Program  Architecture:  The  structure  used  in  com¬ 
puter  program  design  throughout  the  system,  including  allo¬ 
cation  of  functions  to  elements  of  the  computer  programs; 

4 .  Software  Definition,  Design,  and  Implementation  Methods: 
Techniques  used  in  software  system  design  management  and 
control,  especially  those  that  have  had  apparent  success; 

5.  Software  Validation  and  Integration  Methods:  Management 
techniques,  testing  tools  and  techniques,  and  facilities 
used  in  software  quality  assurance; 
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6.  Software  Acquisition  Management  Organization  and  Methods: 
Methods  used  by  the  Government,  system  contractor,  and  soft¬ 
ware  contractor  to  manage  the  process  of  software  design  and 
validation;  and 

7 •  Operational  Software  Maintenance;  Approach  used  or  plans 
for  transfer  of  developed  software  to  Government  control  for 
lifetime  support  and  maintenance. 

Each  paragraph  in  the  Highlights  section  for  each  Weapon  System 
is  followed  by  one  or  more  designations  (e.g.  (SE1))  in  parentheses. 
These  designation(s)  indicate  the  APL  recommendation(s)  from  the  main 
report  that  correlate  most  closely  with  the  particular  highlight. 


1.2  AIRBORNE  SYSTEMS 

The  four  airborne  systems  selected  for  study  represent  several 
evolutionary  lines  of  system  development  that  provide  the  Fleet  with  Air¬ 
borne  Early  Warning  (AEW) ,  Antisubmarine  Warfare  (ASW)  capability,  and 
fighter-interceptor  capability. 

The  E-2C  Tactical  Data  System  evolved  in  early  1970  from  the 
E-2B  and  was  deployed  in  1974.  It  incorporated  a  new  radar,  display 
system,  and  passive  detection  system.  The  first  AEW  aircraft  of  this 
series,  the  E— 2A,  employed  a  drum  computer.  The  L— 304F  computer  selected 
for  E-2B  and  E-2C  was  the  first  airborne  multiprocessor. 

The  P-3C  and  S-3A  Airborne  Systems  are  interrelated  developments 
that  stem  from  exploratory  work  at  the  Naval  Air  Development  Center 
(NADC)  in  Warminster,  Pennsylvania.  These  systems  have  automated  the 
tasks  of  acoustic  submarine  detection  and  tracking,  and  assist  in  air¬ 
craft  direction.  Several  computers  have  been  used.  The  latest,  the 
Univac  1832,  is  similar  to  the  AN/UYK-7  computer  used  in  shipboard  ap¬ 
plications. 

The  platform  for  the  F-14  Avionics  and  Weapon  Delivery  System  is 
the  F-14  Tomcat,  a  carrier-based  fighter  interceptor  aircraft.  The 
AN/AWG— 9  weapon  control  system  used  provides  a  significant  increase  in 
weapons  and  surveillance  capability  over  previous  interceptors.  Im¬ 
proved  data  links  between  this  aircraft  and  surface  units  provide  closer 
coordination  of  surface  and  airborne  defensive  actions.  Separately  de¬ 
veloped  computer  programs  are  used  in  the  weapon  control  system  and  in 
the  avionics  system.  The  Weapon  System  development  started  in  the  early 
1960's  and  later  became  part  of  the  F-14  aircraft.  The  first  F-14  opera¬ 
tional  squadrons  deployed  in  1974. 
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Table  1-2  lists  the  computers  employed  in  these  four  systems. 
There  has  been  less  tendency  to  standardize  computer  equipments  for  air¬ 
borne  systems  than  for  shipborne  systems.  Current  plans  for  an  All- 
Application  Digital  Computer  (AADC)  may  provide  a  modular  family  of  com¬ 
puters  that  will  meet  the  constraints  of  airborne  systems. 


TABLE  1-2 

AIRBORNE  COMPUTERS 


Computer 

Designation 

Word  Length 
(bits) 

Cycle  Time 
(ys) 

System 

No.  CPU's 

OL-77/ASQ 
(Litton  L-304F) 

32 

2.2 

E-2C 

2 

CP901/ ASQ-114 (V) 

30 

2 

P-3C 

1 

AYR- 10 

32 

1.5 

S-3A 

2 

CDC  5400B 

24 

1 

F-14 

1 

Teledyne  CP-1050 

20 

7.5 

F-14 

1 
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Table  1-3  lists  visits  made  to  Program  Managers,  support  actlvi 
ties,  and  contractors  in  pursuit  of  information  relating  to  these  pro¬ 
grams. 

TABLE  1-3 

WEAPON  SYSTEM  PROGRAM  VISITS 


Weapon  System  Date 

Program  Agency  Visited  Responsibility  (1975) 


NAVAIR  PMA  231A  Program  Manager  V 

NAVAIR  533  Comp,  and  Software  2/ 

Agent 

FCDSSA(SD)  Maintenance  Agent  2/ 

Grumman  System  Contractor  3/ 

NAVAIR  533  Comp,  and  Software  2 t 

Agent 

NADC  Advanced  Development  3 i 

Agent,  System  Con¬ 
tractor 

NAVAIR  533  Comp,  and  Software  2t 

Agent 

Lockheed  System  Contractor  3; 

NAVAIR  PMA  241  VM  Program  Manager  3/ 

NAVAIR  5331  System  Development  2/ 

Agent 

NMC,  Pt.  Mugu  Maintenance  Agent  3/ 


Hughes,  Los  Angeles  AWG-9  System  Contractor 


Grumman,  Pt.  Mugu  F-14  Contractor  5 
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2. 
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Program  Executive  Functions  . 
Subprogram  Functions 
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Automatic  Diagnostics  and  Casualty 
Capabilities  .  .  .  . 


2.4  Software  Definition,  Design,  and  Implementation 


2.4.1  Software  Definition 

2.4.2  Software  Design 

2.4.3  Software  Implementation 


2.5  Software  Validation  and  Integration 


2.5.1  ATDS  Monitor /Operating  System 

2.5.2  Mission  Simulator  . 

2.5.3  Data  Extraction/Data  Reduction 


2.6  Software  Acquisition  Management  Organization  and 
Methods  ........ 
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2.  E-2C  TACTICAL  DATA  SYSTEM 


2.1  GENERAL  SYSTEM  DESCRIPTION 

The  E-2C  is  a  carrier-based  airborne  tactical  data  and  control 
system  that  provides  radar  early  warning,  passive  detection,  interceptor, 
and  strike  control  capabilities. 

The  E-2C  evolved  in  early  1970  from  the  E-2B  and  was  deployed  in 
September  1974.  Primary  improvements  over  the  E-2B  involved  the  addi¬ 
tion  of  a  passive  detection  system  (ALR-59),  a  new  radar  (APS-120)  ,  and 
a  new  display  system  (APA-172).  The  E-2C  uses  the  same  L-304  computer 
as  the  E-2B.  The  Navy  software  maintenance  organization,  Fleet  Combat 
Direction  Systems  Support  Activity  (FCDSSA) ,  was  a  party  to  the  software 
development  phase,  becoming  involved  in  the  early  stages  by  assisting 
NAVAIR  in  writing  the  Functional  Operational  Specifications,  Naval  Air 
Test  Center  (NATC)  and  C0M0PTEVF0R  also  provided  support.  A  development 
contract  (fixed  price  and  incentive)  was  awarded  to  the  system  develop¬ 
ment  contractor,  Grumman  Aerospace  Corporation, with  a  separate  line  item 
for  software  development.  Software  design,  generation,  and  validation 
were  conducted  by  Grumman  using  the  software  facility  and  system  inte¬ 
gration  test  site  at  their  Bethpage  facility.  The  software  program  was 
heavily  documented.  Direct  FCDSSA  involvement  in  the  review  and  ap¬ 
proval  of  the  Grumman  test  and  evaluation  plans  proved  highly  beneficial 
to  program  reliability  upon  system  deployment  in  September  1974.  Transi¬ 
tion  of  software  from  the  contractor  to  Navy  maintenance  control  was 
relatively  smooth  because  of  FCDSSA  involvement  in  the  development  phase. 

The  E-2C  Airborne  Tactical  Data  System  (ATDS)  uses  three  program¬ 
mable  computers.  A  dual-processor  L-304F  computer  is  the  central  proces¬ 
sor.  It  performs  the  multisensor  tracking  and  correlation,  navigation 
and  intercept  vectoring,  data  link  communication,  and  display  generation 
functions.  Special  purpose  computers  are  used  in  the  passive  detection 
and  navigation  systems.  Figure  2-1  shows  a  schematic  of  the  E-2C  tacti¬ 
cal  data  system,  and  Fig.  2-2  shows  the  system  in  more  detail. 

An  extensive  correlation  capability  combines  responses  from  radar, 
passive  detection,  IFF,  and  data  links.  The  system  has  a  capability  of 
300  radar  and  IFF  tracks  and  350  passive  detection  reports  and  remote 
tracks,  for  a  total  track  capacity  of  650. 

The  E-2C  airborne  system  can  accomplish  the  following  objectives: 


1.  Detect,  identify,  and  track  airborne  and  surface  targets; 
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Fig.  2-1  E-2C  Tactical  Data  System  Schematic 
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2.  Perforin  threat  assessment; 

3.  Receive  and  display  status  information  on  interceptor  and 
strike  aircraft; 

4.  Receive  and  display  tactical  data  from  the  Naval  Tactical 
Data  System  (NTDS) ,  the  Marine  Tactical  Data  System  (MTDS) , 
and  other  tactical  data  aircraft; 

5.  Compute,  display,  and  transmit  command  data  for  control  of 
interceptors  and  strike  aircraft;  and 

6.  Compute,  display,  and  transmit  tactical  data  to  the  NTDS 
and  MTDS. 


2.2  COMPUTER  SYSTEM  ARCHITECTURE 

2.2.1  Computer  Characteristics 

The  E-2C  AEW  system  uses  three  programmable  computers.  A  dual¬ 
processor  L-304F  computer  is  the  prime  central  processor.  It  performs 
the  tracking,  navigation  and  intercept  vectoring,  data  link  communication 
and  display  generation  functions.  Ar.  ARMA-1808  computer  is  used  in  the 
Passive  Detection  System  (PDS)  to  identify  and  classify  radar  emissions. 
An  LC  728  computer  is  used  in  the  Navigation  System.  Only  the  L-304 
computer  and  program  will  be  examined  in  detail  in  this  ~eport .  A  sum¬ 
mary  for  the  L-304F  computer  is  shown  in  Table  2-1. 


TABLE  2-1 


E-2C  COMPUTER  SUMMARY 


Unit 

Type 

Func  t ion 

1 

Processor 

Memo  ry 

Cl 

Litton  L-304 
(OL-77/ASQ) 

(32  bit,  2.2  ps) 

Sensor  processing  and 
correlation  Link  11  con¬ 
trol,  test,  and  monitoring 

1 

80k 

C2 

Litton  L-304 
(OL-77/ASQ) 

(32  bit,  2.2  ps) 

Navigation,  display,  in¬ 
tercept/strike  control, 
Link  4  control,  test,  and 
monitoring 

1 
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After  deployment  of  the  E-2A  aircraft,  the  requirement  for  im¬ 
proved  reliability  in  the  computer  system  led  to  a  replacement  of  the 
drum  computer  used  in  the  E-2A.  At  that  time,  in  the  mid-1960's,  the 
L-304  computer  was  the  best  choice  for  aircraft  use  where  size,  weight, 
and  computer  processing  power  were  considered  the  key  factors.  A  dual¬ 
processor  configuration  was  selected  to  provide  a  large  growth  margin  in 
the  computing  system.  A  hardware  configuration  was  selected  that  per¬ 
mitted  the  use  of  up  to  80»000  words  of  memory.  The  E-2B  was  the  first 
airborne  multiprocessing  system. 

The  L-304  computer  deployed  for  the  E-2C  has  a  memory  capacity 
of  64k  words  (expandable  to  80k).  There  are  two  CPU's,  each  with  a  mem¬ 
ory  cycle  time  of  2.2  ps  and  the  capability  for  64  levels  of  interrupt 
with  eight  hardware  registers  per  level.  Each  processor  also  has  six 
clocks  that  can  generate  interrupts  based  on  specified  countdown  times. 
The  L-304  also  has  a  dedicated  4k  memory  module  that  performs  the  dis¬ 
play  refresh  function.  The  display  symbol  stroke  data  and  the  file  of 
symbol  parameters  to  be  displayed  are  contained  in  this  memory  and  are 
updated  by  the  computer  program. 

A  single  magnetic  tape  is  used  in  the  system  for  the  purpose  of 
loading  any  of  the  available  program  configurations,  the  tactical  data 
entry,  and  for  data  extraction.  For  example,  the  contents  of  a  recently 
deployed  load  tape  are  given  below: 

Bootstrappable  Loader, 

Fault  Isolation  Program  for  the  Computer, 

Operational  Program  (two  copies)  (eight  memory  module  configura¬ 
tion)  , 

Casualty  Configuration  Program  (two  copies)  (seven  memory  module 
configuration) , 

Passive  Detection  System  Programs  (loaded  through  L-304) , 
Geographic  Point  Files  (three  copies), 

Intelligence  Files  (three  copies),  and 
Data  Extraction  Files. 

2.2.2  Interrelation  Among  Computers 

While  the  application  programs  in  the  L-304  computer  are  allo¬ 
cated  to  specific  CPU's,  the  system  data  are  shared  between  the  two  CPU's 
in  common  memory.  The  rules  for  use  of  common  memory  and  the  interlock 
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involved  between  CPU's  are  handled  entirely  within  the  application  pro¬ 
gram.  Input/output  (I/O)  interfaces  to  external  devices  are  also  dedi¬ 
cated  to  particular  CPU's,  but  in  case  of  an  I/O  failure  both  the  asso¬ 
ciated  task  and  the  I/O  function  can  be  switched  to  the  other  CPU. 
Inter-CPU  interfaces  are  generally  data  only.  Inter-CPU  interrupts  are 
used  very  little.  For  the  most  part,  common  data  usage  does  not  require 
CPU  lockout  for  data  changing.  The  primary  functions  that  require  lock¬ 
out  are  additions  and  deletions  of  tracks  to  the  track  file  because  of 
the  chain  linkage  required  within  the  track  file. 

The  L-304  computer  and  the  PDS  computer  communicate  via  an  I/O 
channel.  The  PDS  computer  program  is  loaded  from  magnetic  tape  via  the 
L-304. 

2.2.3  Functional  Interfaces  with  Sensors 

The  sensor  inputs  used  to  perform  tracking  in  the  L-304  computer 
are  provided  by  the  AN/APS-120  radar,  the  IFF  Interrogator  RT-988/A,  and 
the  PDS. 


The  AN/APS-120  radar  is  a  long-range,  high-resolution,  airborne 
early  warning  radar  that  provides  basic  sensor  input  required  for  detec¬ 
tion  of  air  and  surface  targets.  The  radar  has  an  Airborne  Moving  Tar¬ 
get  Indicator  that  permits  the  detection  and  tracking  of  air  targets  im¬ 
mersed  in  land  and  sea  return.  The  AN/APS-120  radar  is  interfaced  to 
the  L-304  computer  via  the  Radar  Detector  Processor  (RDP)  OL-93/AP. 


The  RDP  is  a  special-purpose  digital  processor  that  detects 
echoes  present  in  video  signals  received  from  the  radar,  associates  ap¬ 
plicable  azimuth  information  with  the  echo  range,  determines  range  dis¬ 
placement  of  the  echo  during  the  detection  process,  arranges  the  data  in 
a  digital  format  for  the  L-304,  and  delivers  such  data  upon  request. 

The  L-304  must  associate  echoes  originating  from  the  same  target  on  sep¬ 
arate  transmissions  in  order  to  determine  a  centroid  azimuth  position. 

It  associates  multiple  returns  on  a  single  transmission  to  determine 
target  height.  The  resulting  centroid  position  is  used  for  track  entry 

and  update. 

The  IFF  Interrogator  RT-988/A  is  an  IFF  interrogation  set  that 
challenges  aircraft  and  identifies  friendly  aircraft  by  their  response 
to  challenge  signals.  The  IFF  transmitter  sends  out  the  challenge  sig¬ 
nals.  Replies  from  friendly  aircraft  are  detected  by  the  receiver  and 
fed  to  the  IFF  Detector  Processor  (IDP)  (OL-76/AP)  and  to  the  Control 
Indicator  AN/APA-172  for  display. 


The  IDP  is  a  special-purpose  digital  processor  designed  to  oper¬ 
ate  on  IFF  video  and  to  provide  position  and  IFF  information  on  each  de¬ 
tected  target,  in  digital  format,  to  the  L-304.  It  also  supplies  delayed 
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code  video,  passive  decode  video,  and  IFF  synthetic  video  to  the  Control 
Indicators.  In  addition,  it  automatically  alerts  the  operators  to  emer¬ 
gency  IFF  replies.  The  L-304  must  perform  the  beamsplitting  and  height 
determination  on  IDP  inputs,  just  as  it  did  with  RDP  inputs. 

The  PDS  AN/ALQ(  )  provides  threat  information  to  the  L-304. 

The  L-304  processes  and  correlates  this  information  with  track  data  de¬ 
rived  from  RDP  and  IDP  reports.  The  PDS  contains  a  programmable  computer 
that  interfaces  directly  to  the  L-304. 

2.2.4  Functional  Interface  with  Displays 

The  Combat  Information  Center  (CIC)  of  the  aircraft  contains 
three  identical  display  consoles.  Each  console  consists  of  two  CRT's, 
one  in  the  Main  Display  Unit  (MDU)  and  one  in  the  Auxiliary  Display  Unit 
(ADU) .  The  MDU  displays  the  tactical  situation  in  PPI  form,  using  both 
computer-generated  video  (symbols)  and  raw  radar  and  IFF  video.  By  us¬ 
ing  a  light  pen,  the  operator  can  "hook"  targets  on  the  MDU  and  can  com¬ 
municate  with  the  computer.  The  ADU  displays  computer-stored  alphanu- 
merics  for  any  information  requested  by  the  operator. 

The  three  operators  that  man  these  consoles  are  the  aircraft 
control  officer  (ACO) ,  the  combat  information  center  officer  (CICO) ,  and 
the  radar  operator  (RO) .  Although  these  operator  stations  have  specific 
names,  the  system  is  designed  such  that  any  operator  console  can  be  used 
to  perform  any  of  the  system  functions.  The  allocation  of  functions  to 
be  performed  by  each  operator  is  made  by  the  CICO  depending  upon  the 
tactical  situation. 

The  symbol  generation,  range  scale  processing,  and  function  but¬ 
ton  processing  are  all  done  in  computer  software.  The  refresh  function 
is  performed  by  a  special  4k  memory  module  in  the  L-304.  The  L-304  can 
display  250  symbols  on  each  display  console. 

2.2.5  Interfaces  with  Navigation  Equipment 

In  order  to  perform  the  navigation  computing  function,  the  L-304 
interfaces  with  the  Carrier  Aircraft  Inertial  Navigation  System  AN/ASN- 
92(V)  (CAINS),  the  Doppler  Navigation  Set  AN/APN-153(V) ,  the  Air  Data 
Computer  (ADC)  A/A,  the  Heading  Attitude  Reference  System  (HARS)  AN/ASN- 
50,  and  the  Navigation  Display  Group. 

The  CAINS  uses  the  aircraft  doppler  radar  system  for  inertial 
damping  during  flight.  During  alignment  on  the  carrier,  the  CAINS  ac¬ 
cepts  carrier  position  data  from  the  interfaced  Ships  Inertial  Naviga¬ 
tion  System  by  a  data  link  system.  CAINS  may  also  be  aligned  on  the 
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ground  and  in  flight.  The  CAINS  provides  five  in-flight  modes  of  navi¬ 
gation:  doppler- inertial,  inertial,  doppler ,  air  data,  and  attitude 
heading.  The  computer  is  programmed  to  select  the  best  of  these  modes. 
The  computer  choice  can  be  overridden  by  the  operator  at  any  time. 

The  Navigation  Radar  (APN-153)  is  an  all-weather,  pulsed  radar. 

It  supplies  ground  speed  and  drift  angle,  in  pulse  form,  to  the  L-304. 

The  doppler  radar  set  operates  independently  of  any  ground  installation 
and  operates  either  in  conjunction  with  the  CAINS  or  alone,  as  a  backup 
system  using  vertical-gyro  information.  The  combined  information  from 
the  doppler  radar  set  and  from  the  inertial  navigation  system  is  sent  to 
the  computer  indicator  group,  resulting  in  a  precise  computation  of  the 
aircraft  velocity. 

The  ADC  A/A-(  )  is  a  solid-state  digital  computer  that  accepts 

air  data  inputs  operating  between  75  to  450  kts  (true  airspeed)  and  from 
1000  to  41,000  ft  altitude.  The  ADC  accepts  three  inputs:  static  pres¬ 
sure,  total  pressure,  and  total  temperature.  These  inputs  are  converted 
into  analog  and  digital  outputs:  true  airspeed,  impact  pressure,  baro¬ 
metric  altitude,  altitude  control,  and  fault  signals.  These  outputs  are 
supplied  to  the  Automatic  Flight  Control  System  AN/ASW-15,  L-304  com¬ 
puter,  CAINS  AN/ASN-92 (V) ,  and  IFPM  Test  Set-Monitor  AN/ASM-440. 

The  HARS  provides  heading  and  attitude  information  in  the  form 
of  continuous  signal  outputs  representing  the  displacement  of  the  air¬ 
craft  about  the  pitch,  roll,  and  azimuth  axes.  The  Signal  Data  Con¬ 
verter  (SDC)  CV-2867/ASN-50  in  the  HARS  is  the  digital  interface  be¬ 
tween  HARS  and  either  the  L-304  computer  or  Control  Indicator  AN/APA-172. 
The  SDC  provides  a  secondary  derivation  of  true  heading  using  magnetic 
heading  (from  HARS)  and  magnetic  variation  inputs  in  synchro  format  from 
CAINS.  The  SDC  converts  the  true  heading  and  magnetic  heading  data  to 
serial-digital  format. 

The  Navigation  Display  Group  consists  of  Computer  Control  Panel 
C-3488/ASA-27,  Navigation  Control  Indicator  C-3489/ASA-27 ,  Navigation 
Coding  Unit  MX-3308/ASA-27 ,  and  Power  Supply  PP  6642/AS.  Computer  Con¬ 
trol  Panel  C-3488/ASA-27 ,  located  in  the  cockpit,  controls  the  input  of 
navigation  data  to  the  L-304  computer  by  selecting  the  desired  naviga¬ 
tion  mode.  Navigation  Control  Indicator  C-3489/ASA-27 ,  also  in  the 
cockpit,  displays  navigation  data  processed  by  the  L-304  computer  and 
has  controls  for  manual  insertion  of  data  into  the  L-304  for  processing. 
Navigation  Coding  Unit  MX-3308-ASA-27 ,  located  in  the  nose,  distributes 
power  and  signals  to  Computer  Control  Panel  C-3488/ASA-27  and  Navigation 
Control  Indicator  C-3489/ASA-27. 
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2.2.6  Functional  Interfaces  with  Communications  Equipment 

The  L-304  computer  is  interfaced  with  Receiver-Transmitter  AN/ 
ARC-51A  and  Data  Radio  Set  AN/ARQ-34  in  order  to  perform  its  interceptor 
control  funtion  and  to  provide  tactical  data  to  NTDS  aboard  the  aircraft 
carrier  or  other  E-2C  aircraft.  The  AN/ARC-51A  provides  UHF  Link  11  and 
Link  4  operation  as  well  as  UHF  voice  communication.  fhe  AN/ARQ-34  pro¬ 
vides  HF  Link  11  operation. 

2.2.7  Functional  Interfaces  with  In-Flight  Test  Equipment 

The  In-Flight  Performance  Monitor  (IFPM)  Test  Set-Monitor  AF/ 
ASM-440  detects  faults  within  the  aircraft  avionic  systems  and  assists 
the  operator  in  isolating  the  system  malfunctions  to  the  Weapon  Replace¬ 
able  Assembly  (WRA)  level.  Six  Signal  Data  Converter  CV-2866/ASM-440 
units  are  used  as  the  interface  between  the  L-304  computer  and  the  avi¬ 
onics  equipment  to  store  and  transmit  fault  (alarm)  Information  and  op¬ 
erator-actuated  commands  to  initiate  diagnostic  tests  and  to  select 
critical  test  points  for  remote  display.  The  signal  selected  for  dis¬ 
play  is  fed  through  the  multiplexer  unit.  This  unit  is  a  solid-state 
device  that  can  select  any  one  of  128  test  points  from  15  different 
equipments  for  routing  to  the  CIC  compartment.  The  test  signal  is  then 
displayed  on  Oscilloscope  0S-144/ASM  or  Multimeter  ME-252/ASM. 


2.3  COMPUTER  FROGRAM  ARCHITECTURE 
2.3.1  Program  Architectural  Structure 

In  the  L-304  assembly  language  nomenclature,  the  complete  tacti¬ 
cal  program  consists  of  programs,  subroutines,  tables,  and  items.  The 
programs  are  simply  core  allocations  for  a  set  of  subroutines,  and  they 
correspond  to  a  major  function  of  the  total  program,  such  as  tracking, 
navigation,  etc.  These  programs  will  be  referred  to  hereafter  as  sub¬ 
programs.  Each  subprogram  may  contain  several  different  sections  cor¬ 
responding  to  different  tasks.  Each  section  consists  of  several  sub¬ 
routines.  One  of  these  subroutines  is  an  Executive  that  calls  the  other 
subroutines  as  required.  Some  subroutines  also  call  each  other  indi¬ 
rectly. 

The  program  executes  in  a  dual  computer,  multiprocessing  con¬ 
figuration.  Specific  functions  are  assigned  to  each  computer  with  a 
few  functions,  such  as  the  Executive  and  File  Control,  being  executed 
by  both.  Conflicts  in  data  accessing  between  the  two  processors  are 
avoided  by  carefully  splitting  up  the  processing  in  terms  of  time  and 
geographic  areas.  Various  functions  are  performed  sequentially  on  par¬ 
ticular  data  items,  so  that  both  processors  do  not  simultaneously  access 
the  same  data. 
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Each  of  the  various  sections  of  the  subprograms  is  assigned  a 
fixed  priority  level  within  the  appropriate  processor.  The  multiple 
real-time  clocks  are  used  to  generate  interrupts  at  various  rates  to 
cause  periodic  interrupt  calls  to  particular  program  levels.  Once  a 
particular  level  is  executed  it  can  generate  an  interrupt  that,  in  turn, 
causes  transfer  to  another  program  level.  This  in  effect  generates  a 
call  from  one  subprogram  to  another.  The  levels  for  each  function  are 
carefully  chosen  so  that  data  conflicts  do  not  result  from  a  program  be¬ 
ing  suspended  by  a  higher  level  interrupt  program  that  operates  on  the 
same  data. 

As  an  example  of  the  subprogram  organization,  the  tracking  sub¬ 
program  contains  subroutines  to  perform  the  following  functions: 

1.  RDP/IDP  I/O  Control, 

2.  RDP/IDP  Echc/Report  Processing, 

3.  Report/Track  Association, 

4.  Report/Track  Correlation, 

5.  Tracking,  and 

6.  Track  File  Control. 

These  subroutines  are  executed  in  sequence  to  process  each  8° 
sector  of  data.  Each  of  these  subroutines  is  executed  at  a  different 
priority  level  in  the  processor.  Information  is  passed  from  one  subrou¬ 
tine  to  the  next  via  data  files. 

The  program  structure  is  modular  in  the  sense  that  functions  are 
isolated  into  relatively  independent  sections  of  code.  However,  it  is 
not  modular  in  the  strictest  sense  because  control  can  flow  directly 
from  one  module  to  another  and  is  not  under  the  control  of  a  central, 
scheduling  executive. 

2.3.2  Program  Executive  Functions 

The  Executive  subprogram  performs  several  housekeeping  and  diag¬ 
nostic  functions,  but  it  does  not  do  scheduling  operations  that  are 
typically  performed  by  an  Executive.  The  Executive  function  is  per¬ 
formed  by  assigning  the  64  levels  of  interrupts  available  in  the  pro¬ 
cessor  to  the  various  functions.  With  dedicated  hardware  registers  for 
each  level  of  interrupt,  an  interrupt  uses  only  about  12  ps  of  overhead 
time,  and  the  Executive  program  is  not  involved  in  requesting  or  pro¬ 
cessing  an  interrupt.  Interrupts  are  generated  periodically  by  the  six 
countdown  clocks  and  also  on  demand  by  the  subprograms  themselves. 
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The  scheduling  type  of  Executive  was  carefully  studied  but  was 
rejected  because  of  execution  time  considerations.  The  study  concluded 
that  a  scheduling  Executive  would  add  5%  overhead  and  that  under  heavy 
loads  this  would  cause  program  execution  to  exceed  100%  of  the  available 
time.  If  load  leveling  between  the  two  processors  had  been  a  problem, 
a  scheduling  Executive  would  have  been  advantageous.  But  load  leveling 
problems  were  avoided  by  carefully  allocating  the  functions  to  each  pro¬ 
cessor  so  that  they  were  loaded  equally. 

The  Executive  performs  the  program  initialization  function.  It 
is  then  run  alternately  in  each  processor  at  a  200  ms  rate  in  each.  It 
services  certain  operator  requests  dealing  with  system  restarting  data 
recording,  diagnostic  execution,  and  fault  monitoring.  It  periodically 
schedules  the  Signal  Command  Readout  and  Alarm  Module  (SCRAM)  subprogram, 
which  performs  in-flight  performance  monitoring.  It  monitors  diagnostic 
error  indicators  provided  by  other  subprograms  and  notifies  the  operator 
of  these  errors. 

The  Executive  performs  a  cross  check  each  time  it  is  called  to 
determine  if  the  other  processor  is  operating.  If  the  other  processor 
is  "hung  up"  in  an  I/O  loop,  it  attempts  to  correct  the  problem  by  switch¬ 
ing  to  the  other  processor.  If  the  problem  persists,  it  switches  to 
the  one  computer  mode. 

The  Executive/System  Control  subprogram  occupies  3200  decimal, 

32  bit  words  in  core.  It  executes  for  approximately  500  ys  out  of  every 
200  ms  (0.25%)  in  the  normal,  no  fault  mode. 

2.3.3  Subprogram  Funct ions 

The  L-304  subprogram  functions  include  tracking,  navigation  and 
interception  vectoring,  data  exchange  via  Data  Link,  and  generation  of 
display  data.  To  perform  target  tracking,  the  L-304  processes  target 
reports  from  Radar  Detector  Processor  Group  OL-93/AP,  Detector  Processor 
Group  OL-76/AP,  and  displays  target  status  (threat  or  nonthreat),  posi¬ 
tion,  height,  and  speed.  The  entered  data  are  instrumental  in  updating 
previously  stored  information,  in  sending  tactical  data  via  Link  11  to 
the  NTDS  aboard  the  aircraft  carrier  or  the  ATDS  of  other  E-2C  aircraft, 
in  turning  over  certain  decision-making  functions  to  the  L-304,  and  in 
assigning  and  directing  interceptor  aircraft  manually  or  via  Link  4  auto¬ 
matically.  Link  4  data  and  Link  11  input  data  are  automatically  corre¬ 
lated  with  local  radar  and  IFF  tracks.  The  tracks  from  the  PDS  are  man¬ 
ually  correlated  with  other  tracks. 

The  system  has  a  tracking  capacity  of  300  radar  and  IFF  tracks, 

350  remote  tracks,  geographic  points,  and  PDS  tracks.  The  total  track 
capacity  is  650;  the  original  E-2C  specification  called  for  300. 
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During  the  interceptor  control  function,  each  interceptor  as¬ 
signed  to  the  aircraft  transmits  information  on  interceptor  type,  arma¬ 
ment,  fuel  supply,  and  position  to  the  L-304  (via  Data  Link)  where  it  is 
evaluated  and  either  stored  or  used  to  update  previously  stored  informa¬ 
tion.  When  an  interceptor  is  selected  to  engage  a  target,  the  L-304 
generates  type  of  mission,  speed,  altitude,  heading,  range-to-target , 
etc.,  and  transmits  this  to  the  selected  interceptor  by  the  Data  Link 
System. 

During  the  navigation  computing  function,  the  L-304  processes 
data  from  CAINS  AN/ASN-92(V) ,  from  Doppler  Navigation  Set  AN/APN-153(V) , 
from  Air  Data  Computer  A/A,  from  RARS  AN/ASN-50,  and  navigation  data 
manually  entered  by  the  pilot  or  copilot.  The  L-304  generates  and  dis¬ 
plays  to  the  pilot  and  copilot  ownship  position,  ground  track,  magnetic 
heading,  true  heading,  drift  angle,  bearing  and  range- to-carrier  center, 
barrier  pattern,  wind  direction  and  speed,  and  bearing  and  range  to 
destination. 

The  E-2C  subprogram  functions  are  listed  in  Table  2-2,  which 
briefly  describes  the  functions  and  lists  the  Central  Processing  Unit 
(CPU)  that  executes  the  module.  In  some  cases,  different  CPU's  execute 
different  parts  of  the  same  subprogram.  In  these  cases  the  CPU  that 
does  most  of  the  processing  is  listed. 
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TABLE  2-2 

TACTICAL  SUBPROGRAMS 

Subprogram 

Primary  Function 

CPU 

Executive 

Detects  and  records  faults,  schedules  IFPM 
function,  processes  operator  program  control 
actions  and  displays. 

A,  B 

Navigation 

Controls  I/O  to  CAINS,  doppler,  HARS,  and 

ADC  navigation  systems.  Evaluates  and  dis¬ 
plays  Navigation  Panel  data.  Updates  own- 
ship  position. 

A 

Track 

Processes  RDP  and  IDP  sensor  data,  corre¬ 
lates  sensor  data  with  tracks,  updates 
tracks,  controls  track  add/drop  function. 

B 

Displays 

Performs  I/O  for  3  CIC  consoles.  Generates 
track  symbol  displays,  alphanumeric  displays, 
and  alerts.  Processes  operator  inputs. 

A 

Intercept/Strike 

Control 

Performs  computations  necessary  to  effect 
vectoring  assignments  against  aircraft  or 
stationary  targets. 

A 

Link  11 

Controls  Link  11  I/O.  Formats  and  deformats 
messages.  Performs  grid  lock  and  automatic/ 
live  association. 

B 

Link  4 

Controls  and  processes  all  incoming  and  out¬ 
going  Link  4A  messages.  Maintains  link  tim¬ 
ing  and  formats,  and  deformats  messages. 

A 

Passive  Detection 

Controls  operation  of  PDS  via  control  mes- 
ages.  Accepts  reports  from  PDS  and  generates 
passive  tracks. 

General  Machine 
Test 

Verifies  operation  of  processors  and  memory. 

A,  B 

SCRAM 


Controls  and  monitors  hardware  IFPM  func¬ 
tions. 
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2. 3. A  Program  Time  and  Core  Requirements 

The  core  and  time  usage  were  carefully  managed  throughout  the 
E-2B  and  E-2C  history  in  order  to  accomplish  the  required  functions  with 
a  minimum  of  computer  resources.  The  original  E-2B  configuration  con¬ 
tained  two  processors  and  56k  of  32  bit  word  length  memory.  Additional 
memory  modules  could  be  added  with  no  hardware  or  software  modification, 
up  to  a  maximum  of  80k.  The  original  E-2B  program  used  only  40k  of  mem¬ 
ory  and  could  have  been  done  with  one  computer.  The  two-computer  config¬ 
uration  was  chosen  for  the  capability  of  expansion  to  meet  future  system 
requirements . 

The  E-2C  tactical  program  occupies  the  entire  6Ak  of  memory  in 
the  current  L-30A  computer  configuration.  An  extra  16k  expansion  capa¬ 
bility  is  still  available  as  was  required  in  the  program  specification. 

The  program  currently  uses  95%  of  the  available  time  in  process¬ 
ing.  The  approximate  core  requirements  of  individual  subprograms  are 
listed  below: 


Executive 

3.2k 

Navigation 

1.7k 

Tracking 

20.5k 

Displays 

17.5k 

Interrupt/Strike  Control 

2.6k 

Link  11 

6.0k 

Link  A 

1.5k 

Passive  Detection 

6 .  Ak 

SCRAM  and  GMT(IFPM) 

3.6k 

Total  63.0k 


The  E-2C  is  now  being  modified  to  operate  with  the  Advanced 
Radar  Processing  System  (ARPS)  radar.  This  will  require  an  additional 
8k  of  memory.  Short-range  future  requirements  will  require  modifica¬ 
tions  to  the  computer  to  obtain  more  memory  and  faster  execution.  It 
is  also  anticipated  that  more  capable  preprocessors  will  be  used  to  de¬ 
crease  the  computer  data  load.  Long-range  future  requirements  (1990) 
will  require  a  new  computer. 

Throughout  the  development  of  the  E-2C  program,  computer  time 
and  core  limitations  caused  several  problems  that  required  specific 
attention  to  resolve. 
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Due  primarily  to  program  requirements  that  were  not  anticipated, 
the  processor  time  resource  was  saturated  under  certain  conditions. 

The  function  that  required  the  greatest  amount  of  computer  time  was  the 
association  of  radar  detections  with  tracks  in  the  track  file.  Also, 
certain  operator  actions  resulted  in  considerable  processor  usage.  To 
meet  the  processor  time  constraints,  certain  functions  had  to  be  de¬ 
leted  or  reduced  in  scope,  and  the  technique  of  using  more  memory  to 
save  processor  time  was  used.  Certain  time-consuming  functions  were 
optimized  to  the  extent  possible. 

The  update  of  the  display  console  symbology  is  performed  by 
using  a  dedicated  4k  memory  module  that  is  part  of  the  L-304  computer. 
The  display  symbol  stroke  data  and  the  file  of  symbol  parameters  to  be 
displayed  are  contained  in  this  memory  and  updated  by  the  L-304  com¬ 
puter.  The  memory  update  function  is  a  time-consuming  computer  function 
and,  as  a  result,  posed  some  problems  to  the  system  design. 

While  the  L-304  computer  Is  capable  of  accepting  10  memory 
modules  of  8000  words  each,  only  8  memory  modules  are  used  in  the  de¬ 
ployed,  system.  The  spare  memory  slots  are  not  usable  in  the  current 
system  in  order  to  guarantee  growth  potential.  Because  of  the  number 
of  functions  performed  and  the  large  files  required,  memory  limitations 
became  a  serious  problem  in  E-2C  development. 

When  the  E-2C  radar  was  initially  operated  at  Long  Island,  the 
combination  of  real  and  false  tracks  immediately  overloaded  the  system 
track  capacity  of  300  tracks.  When  operating  the  E-2C  at  an  altitude  of 
2500  ft,  the  radar  and  IFF  easily  see  more  than  300  actual  tracks  in  its 
coverage  out  to  250  mi.  When  operating  on  the  ground,  the  IFF  routinely 
sees  between  170  and  200  tracks.  To  limit  the  number  of  tracks,  opera¬ 
tor  functions  were  defined  to  limit  the  coverage  of  the  radar. 

2.3.5  Automatic  Diagnostics  and  Casualty  Capabilities 

Several  automatic  diagnostics  and  some  automatic  casualty  re¬ 
configuration  are  used  in  the  E-2C  program.  The  General  Machine  Test 
(GMT)  verifies  the  correct  operation  of  the  processor  instruction  execu¬ 
tion  logic.  It  is  the  lowest  priority  program  function  and  is  continu¬ 
ally  cycled. 

The  SCRAM  subprogram  performs  the  majority  of  all  hardware  IFPM 
functions.  It  is  executed  periodically  every  2.5  to  4  sec  or  immediately 
upon  operator  request.  The  SCRAM  tests  include  test  targets,  alert 
light  test,  voltage  checks,  and  certain  semiautomatic  tests. 

The  Executive  module  performs  a  cross  check  to  determine  if  the 
other  processor  is  operating.  If  a  processor  determines  that  the  other 
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processor  is  stopped  in  an  I/O  loop,  it  will  switch  that  I/O  function  to 
itself.  If  the  second  processor  has  failed,  it  will  switch  to  the  one 
processor  mode.  The  Executive  also  notifies  the  operator  of  any  faults 
detected  in  any  other  module. 


2.4  SOFTWARE  DEFINITION,  DESIGN,  AND  IMPLEMENTATION 

2.4.1  Software  Definition 

Extensive  documentation  was  used  during  the  definition  phase. 

The  primary  requirements  definition  document  for  the  E-2C  system  was  the 
E-2C  Weapon  System  Specification.  Computer  program  requirements  were 
derived  principally  from  this  document,  although  the  contract  also  re¬ 
quired  compliance  with  three  documents  prepared  by  FCDSSA(SD) .  These 
three  documents  (the  System  Operational  Specification  (SOS),  the  Func¬ 
tional  Operational  Specification  (FOS) ,  and  the  Operational  Requirements 
Document  (ORD))  were  used  primarily  as  guides. 

The  SOS  defines  the  requirements  of  the  Tactical  Data  System 
Operational  Program.  The  document  treats  aspects  that  are  primarily  re¬ 
lated  to  program  maintenance,  Fleet  use,  casualty  reaction,  diagnostics, 
and  Link  11  planning.  The  SOS  lists  the  following  as  pertinent  to  the 
specification: 

U.S.  Navy  Book  of  Standards  for  Tactical  Data 

Systems  OPNAVINST  05711. 91A  (NAVTAC STANS ) . 

The  FOS  is  actually  a  series  of  specifications.  Each  specifica¬ 
tion  is  to  be  used  as  a  basis  for  the  design  and  implementation  of  a 
specific  function  and  is  to  contain  limitations  and  equipment  interface 
data  where  applicable. 

2.4.2  Software  Design 

Extensive  documentation  was  also  used  in  the  design  phase.  A 
system  design  for  the  tactichl  program  was  formulated  using  the  above 
douc.ments  and  a  System  Analysis  Document  (SAD).  The  system  design  is 
intended  to  support  the  generation  of  the  detailed  programs;  the  de¬ 
sign  material  itself  is  issued  as  part  of  the  System  Operational  Design 
Document  (SODD). 

Other  software  design  documents  are  used  to  support  the  SODD 
(including  a  guide  for  the  preparation  of  the  SODD).  All  of  these  docu¬ 
ments  (including  the  SODD  itself)  are  described  in  more  detail  in  the 
E-2C  Initial  Program  Plan. 
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These  supporting  documents  include: 

1.  System  Overall  Flow  Diagram  (SOFD) .  This  diagram  includes 
blocks  for  all  peripheral  equipment  communicating  with  the 
computer,  identification  of  all  major  program  functions, 
and  indicates  information  flow  between  blocks; 

2.  Function  Operational  Design  Document  (FODD)  is  a  collection 
of  subprogram  designs  that  are  defined  in  the  SODD.  The 
FODD  establishes  the  subprogram  performance  baseline  and  all 
aspects  of  program  design;  and 

3.  Program  Technical  Description  (PTD) .  This  documents  the 
characteristics  and  capabilities  of  a  particular  software 
function. 

Figure  2-3  illustrates  the  phases  of  the  software  development 
process  with  an  indication  of  the  required  documentation  at  each  phase. 

A  more  detailed  view  of  software  development  is  shown  in  Fig.  2-4. 

2.4.3  Software  Implementation 

Various  methods,  tools,  and  aids  were  used  in  generating  the  ac¬ 
tual  code  from  the  design  documents. 

2. 4. 3.1  Programming  Standards  and  Manuals 

The  previously  mentioned  NAVTACSTANS  provides  standards  for  Tac¬ 
tical  Data  Systems. 

An  example  of  a  manual  used  during  software  implementation  is 
the  E-2C  Programmer's  Reference  Manual.  This  manual  is  intended  to  pro¬ 
vide  all  information  required  by  a  programmer  to  convert  the  diagrammed 
structure  of  the  operational  sequences  of  a  computer  program  to  the  in¬ 
struction  code  for  input  to  the  system  computer.  The  manual  is  written 
for  the  digital  computer  programmers  who  will  prepare  source  programs 
for  the  operational,  test,  maintenance,  simulation,  and  interpreter  rou¬ 
tines  for  the  E-2C  Tactical  Data  System.  The  manual  combines  the  fea¬ 
tures  of  a  basic  programming  manual  and  a  programmer's  reference  manual 
and  will  be  used  in  the  training  of  college-level  personnel  who  have  re¬ 
ceived  special  system  orientation. 

2 . 4 . 3 . 2  Language  and  Frogram  Generation  Facility 

The  LISA  Assembler  (Litton  Industries  Symbolic  Assembler)  was 
chosen  for  the  E-2C  because: 

1.  The  only  candidate  high-level  language  at  the  time  (CMS-2) 
was  not  fully  operational; 
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SOS 


Legend 

SOS  =  System  Operational  Specifications 
FOS  =  Functional  Operational  Specifications 
ORD  =  Operational  Requirements  Document 
SODD  =  System  Operational  Design  Document 
SOFD  =  System  Overall  Flow  Diagram 


FODD 
SAD 
TPDD 
PTD 
T&  EP 


=  Functional  Operational  Design  Document 
=  System  Analysis  Document 
=  Technical  Program  Design  Document 
=  Program  Technical  Description 
=  Test  and  Evaluation  Program 


Fig.  2-3  Software  Development  Schematic 
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2.  A  CMS-2  compile  facility  was  expensive;  and 

3.  The  high-level  code  generation  was  inefficient. 

While  these  were  valid  reasons  at  the  time,  Grumman  now  believes 
that  high-level  languages  should  be  used  whenever  possible  even  though 
the  efficiency  of  the  program  is  not  as  great  as  with  low-level  lan¬ 
guages.  NAVAIR  representatives  emphasized  the  point  that  if  a  standard 
Navy  language  is  adopted,  the  compiler  should  be  written  in  a  machine- 
independent  language  so  that  it  can  run  on  commercial  systems.  This 
then  would  not  require  (expensive)  additional  Navy  equipment  (e.g., 

UYK-7,  etc)  for  program  compilation. 

All  computer  program  development,  checkout,  and  integration  were 
done  at  a  single  facility  at  the  Grumman  site.  Within  the  facility,  a 
section  was  devoted  to  program  assembly  operations  using  the  L-304  com¬ 
puter.  Also,  two  sections  were  available  for  two  integration/checkout 
benches.  By  using  a  flexible  computer  interface  switching  system,  com¬ 
puters  could  be  reallocated  for  various  functions  within  the  facility. 

2 . 4 . 3 . 3  Implementation  Organization 

_  ..—The  number  of  people  required  for  program  development  including 

document at ion  support  and  simulation  was  about  30  people.  The  maximum 
number  o'f  tactical  programmers  employed  was  18.  The  total  number  of  per¬ 
sonnel  including  all  test  program  development  was  70  people.  The  average 
number  over  a  5-yr  period  was  22  people.  Not  including  analysts,  the 
average  output  was  2.5  instructions  per  hour.  Including  analysts'  time, 
about  one  instruction  per  hour  Wets  .achieved .  One  hundred  and  seventy- 
two  thousand  words  of  programming  and  50,000  pages  of  documentation  were 
generated.  Grumman  considered  the  programming  team  to  be  exceptional  in 
terms  of  their  talents  and  motivations.  The  high  level  of  motivation 
resulted  because  the  job  was  interesting,  a  team  effort  was  used,  and 
management  trusted  the  programmers  to  deliver  the  product  without  exten¬ 
sive  internal  reviews.  The  total  cost  of  the  software  development  con¬ 
tract  was  $9,000,000. 

In  the  opinion  of  Grumman,  the  integration  agent  for  a  system 
should  be  the  same  agency  that  does  software  development.  A  number  of 
problems  had  been  experienced  by  Grumman  in  developments  in  which  this 
was  not  the  case.  In  the  case  of  E-2C,  Grumman  was  the  integration 
agent  and  they  also  performed  the  software  development  activity.  How¬ 
ever,  in  E-2A  and  F-2B  the  software  was  developed  by  Litton  and  FCDSSA, 
respectively. 

Three  examples  are  given  showing  the  need  for  a  responsive  soft¬ 
ware  development  agents 
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1.  During  the  development  phase  of  a  contract,  changes  are  in¬ 
evitable  due  to  oversights  in  the  initial  design  or  due  to 
errors  in  analysis  of  hardware  performance.  As  a  result, 
the  software  development  agency  must  be  responsive  to 
changes  without  adding  excessive  cost  or  schedule  delay. 

2.  In  the  checkout  phase  of  development  the  problem  with  an 
independant  software  development  agent  is  that  a  system 
problem  must  be  isolated  explicitly  to  be  software  before 
the  software  agent  will  take  corrective  action.  By  the 
time  the  integration  agent  has  found  the  source  of  the  prob¬ 
lem,  he  could  just  as  easily  correct  the  problem  and  do 
without  the  software  agent. 

3„  During  the  Board  of  Inspection  and  Survey  (BIS)  for  the  E-2C, 
the  E-2C  met  *"he  Weapon  System  specifications,  but  the  BIS 
team  evaluates  the  system  on  its  operational  utility,  not 
whether  the  system  meets  the  specification  or  not.  In  this 
case,  certain  requirements  of  the  E-2C  were  not  met  in  the 
view  of  the  BIS  Committee  and  in  a  period  of  5  weeks  Grumman 
revamped  the  system  to  meet  their  requirements.  In  the  opin¬ 
ion  of  Grumman,  this  would  not  have  been  possible  if  arrange¬ 
ments  with  a  separate  software  development  agency  had  been 
required . 

2.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

The  computer  program  and  checkout  process  was  done  by  the  phi¬ 
losophy  of  build-a-little ,  test-a-little .  Original  planning  schedules 
for  E-2C  programming  showed  the  classic  phases  of  design,  coding,  check¬ 
out,  and  integration.  However,  programming  managers  knew  that  to  per¬ 
form  all  coding  without  any  checkout  and  integration  would  be  disastrous. 
In  addition  to  planned  phasing  of  elements  of  the  program  through  the 
integration  process,  a  number  of  uncontrolled  events  affected  the  devel¬ 
opment  sequence  that  included  delays  in  development  of  hardware  and  in 
requirements  to  demonstrate  progress  through  demonstration  of  the  pro¬ 
gram. 

A  test  team  was  assembled  within  Grumman  Aerospace  Corporation 
(GAC) ,  independent  of  the  programmers,  to  evaluate  the  program  operabil¬ 
ity.  On  other  programs  at  Grumman,  a  common  technique  has  been  to  assem¬ 
ble  a  small  team  for  the  purpose  of  trying  to  defeat  the  system.  In  an¬ 
other  related  activity,  a  team  will  postulate  a  program  fault,  determine 
the  symptoms  that  such  a  fault  will  cause,  and  then  present  these  symp¬ 
toms  to  another  group  whose  job  it  is  to  determine  what  the  cause  of  the 
problem  is.  One  of  the  uses  of  such  an  activity  is  to  determine  exactly 
what  functions  should  be  monitored  in  the  equipment. 
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The  software  test  plan  was  prepared  jointly  by  GAC  and  FCDSSA. 

A  more  comprehensive  and  meaningful  test  resulted.  The  test  phase  was 
very  successful  in  that  it  exposed  many  problems  that  were  corrected, 
resulting  in  a  very  reliable  deployed  system.  Integration  tests  at  a 
test  site  uncovered  about  70%  of  the  problems  with  the  remainder  dis¬ 
covered  in  flight  tests.  In  all,  about  500  trouble  reports  were  issued 
over  the  3-month  test  period. 

The  main  integration/test  facility  is  at  Grumman  (Long  Island) 
and  includes  all  actual  avionics  hardware.  A  second  facility  exists  at 
FCDSSA,  which  is  used  for  program  maintenance  and  development  of  new 
features.  NAVAIP.  expressed  the  opinion  that  a  single  site  for  integra¬ 
tion,  test,  program  development,  and  checkout  was  not  desirable  (two 
are  preferred)  due  to  the  varying  requirements  of  facility  users.  Much 
time  is  wasted  in  determining  what  configuration  the  system  is  set  up 
for  and  converting  to  a  different  setup  when  required. 

The  following  three  programs  are  support  programs  for  software 
integration  and  validation. 

2.5.1  ATDS  Monitor/Operating  System 

The  Airborne  Tactical  Data  System  Monitor/Operation  System  (AMOS) 
is  a  monitor  control  program  together  with  associated  subprograms  for  the 
Digital  Data  Computer  OL-77/ASQ.  AMOS  is  designed  to  perform  the  follow¬ 
ing  functions: 

1.  Control  the  loading  of  object  programs, 

2.  Handle  Digital  Data  Computer  OL-77/ASQ  data  processing  pe¬ 
ripheral  equipment, 

3.  Provide  diagnostic  communications  to  the  operator,  and 

A.  Minimize  the  degree  of  operator  setup  and  intervention  re¬ 
quired  to  assemble  source  and  execute  object  programs. 

2.5.2  Mission  Simulator 

The  E-2C  Mission  Simulator  has  been  developed  to  substitute  con¬ 
trolled  inputs  in  place  of  the  actual  sensor  data  for  the  purpose  of 
checking  out  the  E-2C  Tactical  Program.  The  simulation  system  uses  a 
digital  computer  to  produce  the  desired  inputs  at  a  real-time  rate,  syn¬ 
chronized  with  the  E-2C  computer  and  an  interface  network  to  match  the 
simulator  computer  I/O  to  the  E-2C  I/O  devices.  All  communications  be¬ 
tween  the  simulator  computer  and  the  E-2C  system  are  via  the  Simulator 
Interface  System  (SIS) . 
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Several  levels  of  software  requirements  are  required  for  the 
specific  testing  of  the  E-2C  Tactical  Program.  Each  level  is  designed 
to  check  out  a  different  part  of  the  overall  E-2C  Tactical  Program, 
with  all  leading  to  a  full  mission  simulation  program  to  provide  a  labo¬ 
ratory  operation  representing  actual  flight  environment.  The  simulation 
hardware  consists  primarily  of  the  Varian  6201  Digital  Computer  and  GAC- 
designed  SIS.  Characteristics  of  each  are: 

Computer  System 

1.  16  bit  word 

2.  1.8  ps  cycle  time 

3.  12,288  word  magnetic  core 

4.  16  priority  interrupts 

5.  1  ms,  real-time  clock 

6.  Direct  memory  access 

7.  2  buffer  interlace  con¬ 
trollers 

8.  2  magnetic  tape  controllers 

9.  3  9-track  800  bpi  magnetic 
tape 

10.  ASR  35  teletypewriter 

11.  Line  printer 

12 .  Card  reader 

13.  High-speed  punched  tape 
reader 

2.5.3  Data  Extraction/Data  Reduction 

Support  program  requirements  for  the  test  evaluation  phase  of 
the  E-2C  programming  effort  consist,  as  a  minimum,  of  data  extraction, 
data  editing  for  all  recorded  data,  and  data  reduction  (analysis)  sub 
programs  for  selected  data  groups.  Data  extraction  is  defined  as  re¬ 
cording  on  the  tape  or  printer  selected  core  data  in  binary  format. 

Data  editing  is  the  printing  of  recorded  data  in  an  interpreted  format 
(decimal  values  of  speed,  heading,  position,  etc.).  Data  reduct  on  s 
the  derivation  of  analytical  data  by  computational  analysis  of  the  re¬ 
corded  data  groups  (sigma  deviations,  error  biases,  true  versus  computer 

values,  etc.). 


Interface  System 

1.  20  input  registers  (16  bit) 
serial  to  parallel 

2.  20  output  registers  (16  bit) 
parallel  to  serial 

3.  4  dual  direction  registers 
(16  bit) 

4.  14  control  commands 

5.  5  status  sense  lines 

6.  16  interrupt  lines 


2.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 

2.6.1  Management  Organizations  and  Information 

The  primary  organizations  involved  in  the  E-2C  system  acquisi¬ 
tion  are: 
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1. 

Program  Office 

NAVAIR 

Program  Manager 

Capt.  F.  H.  Roth 
W.  L.  Wagner 

PMA-231 

PMA-231A 

Computer  and 

Software  Group 

P.  L.,  Luppino 

C.  F.  Showalter 

(E-2C/ARPS) 
NAVAIR  533 
(E-2C) 

2. 

System  Contractor 

GAC 

3. 

Software  Contractor 

GAC 

4. 

Validation  Agent 

GAC 

5. 

Integration  Agent 

GAC 

6. 

Maintenance  Agent 

E-2C  Managers 

FCDSSA(SD) 

Cdr.  J.  Dage 

D.  Smith 

The  software  deliverables  included  the  Operational  Program, 
and  Functional  and  Design  Description  documents. 

The  Program  Office  made  use  of  their  in-house  Computer  and 
Software  Group  in  an  advisory  role.  This  group  established  general 
policies  and  procedures  generally  not  available  because  of  the  inade¬ 
quacy  of  OPNAV-generated  specification  instructions.  It  was  felt  that 
instructions  in  existence  at  that  time  (and  to  a  lesser  degree  in  1975) 
actually  increase  costs  when  attempts  to  assure  compliance  are  made. 

Grumman  was  given  the  responsibility  for  software  development 
together  with  the  E-2C  system  development  contract.  Software  develop¬ 
ment  was  specified  as  a  separate  line  item  in  the  system  contract, 
which  was  fixed  price  with  incentive.  The  total  software  development 
cost  (including  R&D,  procurement,  and  documentation)  came  to  approxi¬ 
mately  $13,000,000,  which  is  half  the  E-2C  aircraft  per  unit  cost  of 
$26,000,000.  The  software  contract  called  for  substantial  documenta¬ 
tion.  Clauses  contained  in  the  contract  included  approval  rights  on 
test  plans  and  an  agreement  to  accept  program  changes  requested  before 
specified  dates  at  no  extra  cost.  Software  deliverables  included  docu¬ 
mentation,  program  card  decks,  program  listings,  and  Tactical  System 
magnetic  tapes  in  both  IBM  and  E-2C  system  language. 

FCDSSA  was  tasked  under  separate  contract  to  support  NAVAIR  in 
the  areas  of  program  definition/specifications,  program  and  document 
review,  and  test  planning.  Extensive  Navy  involvement  in  generating 
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comprehensive  test  and  evaluation  plans  contributed  significantly  to 
delivery  of  a  system  that  has  demonstrated  excellent  operational  per¬ 
formance.  FCDSSA  involvement  throughout  the  development  phase  also 
resulted  in  a  smooth  and  rapid  transition  of  software  control  from 
the  contractor  to  the  Navy  maintenance  organization. 

2.6.2  Management  Techniques 

The  total  E-2C  system  performance  responsibility  was  contracted 
to  Grumman  to  avoid  a  division  of  responsibility  that  proved  coctly  on 
the  previous  E-2B  development.  Grumman  provided  the  examples  cited  in 
Section  2.4. 3. 3  to  illustrate  the  need  for  a  responsive  software  develop¬ 
ment  agent. 

The  use  of  a  common  software  and  system  integration  agent  also 
allowed  to  a  greater  degree  the  use  of  overall  system  performance  speci¬ 
fications  in  lieu  of  separate  hardware  and  software  performance  specifi¬ 
cations.  This  allows  the  contractor  to  exercise  independent  control 
over  software  design  and  freedom  in  making  hardware-software  tradeoffs. 

2.6.2. 1  Design  Review  Process 

During  the  development  process,  design  reviews  were  held  between 
Grumman  and  the  Navy  in  which  Grumman  presented  the  design  status  of  the 
software  in  an  informal  way.  Software  development  activity  was  driven 
by  the  program  schedule  and  required  periods  where  extra  work  shifts  and 
long  work  weeks  were  employed. 

2. 6. 2. 2  Quality  Assurance 

No  quality  assurance  requirements  were  specified  for  E-2C  soft¬ 
ware  development.  Grumman  programmers  did  their  own  quality  assurance. 

A  better  approach  would  have  been  to  form  an  independent  quality  assur¬ 
ance  group  to  report  to  the  same  level  of  management  as  the  design 
groups . 


2 . 6 . 2 . 3  Configuration  Control 

The  L-304  CPU  was  used  in  the  E-2B  and  was  retained  for  use  in 
the  E-2C.  No  control  over  software  design  was  exercised  by  the  Navy, 
and  no  formal  acceptance  and  sign-off  of  design  documents  were  required 
by  NAVAIR.  Engineering  change  procedures  were  prescribed  in  the  con¬ 
tract,  which  specified  dates  before  which  the  contractor  would  accept 
changes  at  no  additional  cost  to  the  Navy.  These  changes  were  limited 
to  prescribed  areas.  No  change  would  be  made  that  exceeded  the  hardware 
constraints  in  the  contract  without  NAVAIR  approval. 

The  contract  clause  requiring  approval  of  test  and  evaluation 
plans  proved  highly  beneficial.  However,  these  documents  were  received 
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by  NAVAIR  shortly  before  the  test  phase  was  scheduled  to  begin.  Many 
deficiencies  in  the  documents  made  this  a  serious  problem.  The  prob¬ 
lem  was  solved  only  because  a  one-year  slip  in  the  program  permitted 
NAVAIR  and  FCDSSA  to  work  with  the  contractor  to  revise  the  plans. 

The  test  revisions  subsequently  resulted  in  the  deployment  of  a  system 
that  has  demonstrated  excellent  operational  performance. 

2.6.3  Management  Documents 

The  primary  management  documents  were  the  E-2C  Weapon  System 
Specifications  (SD-527-2)  and  the  E-2C  System  Operational  Specifica¬ 
tions  (SOS-8400)  referred  to  in  the  contract.  Two  additional  control 
documents,  the  FOS  and  the  ORD,  were  provided  to  the  contractor  after 
initiation  of  the  contract.  As  a  result,  these  documents  were  used 
by  GAC  as  guidance  rather  than  as  specifications. 

2.6.4  Documentation  Requirements 

The  software  contract  called  for  extensive  documentation.  The 
following  items  are  a  partial  listing  of  these: 

Initial  Project  Plan, 

System  Operational  Design, 

Functional  Operational  Design, 

Validation  and  Verification  Plan, 

Configuration  Control  Procedures, 

Overall  System  Flow  Diagram, 

*Functional  Test  and  Evaluation  Plan, 

*Flight  Test  and  Evaluation  Plan, 

*Integrated  System  Test  and  Evaluation  Plan, 

*System  Performance  Summary, 

Design  Mannual,  and 
Operational  Manual. 

Documents  marked  with  an  asterisk  required  Navy  review  and  approval. 

It  appears  that  documentation  requirements  may  have  been  excessive, 
and  Grumman  expressed  the  opinion  that  present  standards  result  in 
excessive  duplication  among  documents. 
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2.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

FCDSSA(SD)  assumed  the  life  cycle  maintenance  of  E-2C  on  1  Sep¬ 
tember  1974.  A  test  facility  was  installed  and  was  largely  operational 
at  FCDSSA  by  March  1974.  FCDSSA  was  brought  into  the  E-2C  development 
as  a  consultant  during  the  design  process  providing  the  necessary  ex¬ 
perience  for  the  role  of  life  cycle  maintenance .  Both  NAVAIR  and 
FCDSSA  emphasized  the  early  involvememt  as  necessary  for  smooth  transi¬ 
tion  to  maintenance. 

In  terms  of  achieving  a  reliable  computer  program,  the  E-2C  has 
been  extremely  successful.  In  more  than  1200  hr  of  flight  time  since 
deployment  there  have  been  no  identified  software  failures.  The  com¬ 
puter  hardware  mean  time  between  failure  is  150  hr.  Grumman  credits 
the  good  reliability  of  the  program  to  extensive  testing  at  the  land- 
based  facility. 


2.8  HIGHLIGHTS 

System  growth  requirements  were  recognized  in  the  E-2C  system 
definition  with  the  result  that  a  second  L-304  processor  was  provided 
for  growth.  This  100%  margin  was  expected  to  more  than  absorb  antici¬ 
pated  growth  and  computer  load  due  to  hardware  uncertainties.  However, 
largely  because  of  increased  radar  data  processing  requirements,  all  of 
the  margin  was  used,  causing  costly  tailoring  of  the  software  to  meet 
system  requirements.  (SE2) 

GAC  had  a  complete  integration  and  test  facility  for  the  E-2C 
that  contained  all  the  actual  hardware  used  in  the  system.  It  also  had 
provisions  for  simulating  many  of  the  hardware  interfaces.  A  similar 
facility  was  developed  at  FCDSSA(SD),  the  Operational  Support  Facility. 
The  E-2C  program  has  had  a  very  good  reliability  record,  having  logged 
1200  hr  with  no  software  errors.  GAC  attributes  a  large  part  of  this 
success  to  the  extensive  testing  of  the  system.  (IP3) 

The  E-2C  Program  Manager  (PM)  uses  the  NAVAIR  Computer  and  Soft¬ 
ware  Systems  Group  (Code  533)  as  technical  support  and  review  agent  with 
success.  The  same  agency  is  used  by  several  NAVAIR  PM's  for  this  pur¬ 
pose.  (MS2) 

FCDSSA(SD)  was  tasked  by  NAVAIR  under  separate  contract  to  pro¬ 
vide  support  in  the  areas  of  E-2C  program  definition/specifications,  pro¬ 
gram  and  document  review,  and  test  and  evaluation  planning.  FCDSSA(SD) 
assisted  NAVAIR  in  the  preparation  of  requirements  documents. 

(MS2 ,MS3) 
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Extensive  Navy  involvement  in  creating  comprehensive  test  and 
evaluation  plans  contributed  significantly  to  delivery  of  a  program 
that  has  demonstrated  excellent  operational  reliability.  Navy  involve¬ 
ment  throughout  the  development  phase  also  resulted  in  a  smooth  tran¬ 
sition  of  software  control  from  the  contractor  to  the  Navy  support 
organization.  (MS3) 
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3.  P-3C  AIRBORNE  PATROL  SYSTEM 


3.1  GENERAL  SYSTEM  DESCRIPTION 

The  P-3C  is  a  land-based  Antisubmarine  Warfare  (ASW)  patrol  air¬ 
craft,  with  the  mission  to  perform  ocean  surveillance,  strike  group  and 
convoy  protection,  and  mine-laying  operations.  Detection,  classifica¬ 
tion,  and  weapon  delivery  against  surface  and  subsurface  targets  are 
basic  requirements. 

The  system  is  capable  of  performing  operations  independently  or 
as  a  unit  in  a  coordinated  operation.  It  has  communications  and  data 
link  equipment  to  allow  it  to  perform  coordinated  operations.  Maximum 
endurance  during  either  of  these  types  of  operations  is  about  14  hr. 

Electromagnetic,  infrared,  and  acoustic  sensors  are  used  to¬ 
gether  with  the  visual  capabilities  of  the  crew. 

The  airframe  itself  is  a  version  of  the  Lockheed  Electra  origi¬ 
nally  produced  for  commercial  air  carrier  operations.  The  four  turbo¬ 
prop  engines  provide  speed  capabilities  on  the  order  of  350  kts  and  can 
be  used  in  two  and  three  engine  operations  to  provide  extended  endurance. 

The  aircraft  system  includes  inertia.!,  doppler,  LORAN,  and  TACAN 
navigation  units.  The  data  processing  system  uses  this  and  other  tacti¬ 
cal  information  to  drive  commands  to  a  flight  director  system  for  use  by 
the  pilot. 

Development  started  at  the  Naval  Air  Development  Center  (NADC) 
about  1960.  It  was  originally  pointed  toward  solving  the  S-2  tactical 
coordination  problem  and  then  shifted  to  the  larger  P-3  airframe. 

A  Mod  0  lab  system  was  configured  around  a  32k,  30  bit  CP-901 
computer.  There  followed  a  Mod  1  flying  configuration,  a  Mod  2  lab  ver¬ 
sion,  and  finally  a  Mod  3  flying  version  that  used  an  updated  64k  memory 
of  the  CP-901. 

The  Navy  began  the  P-3C  program  using  the  digital  program  in 
hand  at  NADC.  In  1968  Lockheed  received  the  NADC  Functional  Requirements 
Specifications  (FRS) . 

A  Software  Management  Team  was  established  by  PMA-240  who  dele¬ 
gated  control  to  NAVAIR  533.  The  rer’v' 

Univac,  General  Electric,  NADC,  and  Fleet  Combat  Direction  Systems  Sup¬ 
port  Activity,  Dam  Neck  (FCDSSA(DN) ) .  Periodic  design  reviews  were  held, 
and  design  approaches  were  validated  and  demonstrated  at  the  Integration 
Test  Facility.  VX-1  ultimately  conducted  an  OPEVAL. 
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Upon  delivery  to  the  Fleet,  FCDSSA(DN)  took  over  maintenance 
support  responsibility.  Eight  major  versions  of  the  program  have  since 
evolved. 

Version  A  of  the  P-3C  Operational  Program  was  delivered  by  Lock¬ 
heed  in  January  1969.  At  that  time  a  Software  Configuration  Control 
Board  (SCCB)  was  formed.  In  July  1969,  version  C  was  delivered.  Ver¬ 
sion  F,  including  ESM  functions,  was  also  delivered  by  Lockheed. 
FCDSSA(DN)  has  developed  subsequent  versions. 

Figure  3-1  shows  a  schematic  of  the  P-3C  System.  Figure  3-2 
shows  the  P-3C  system  block  diagram  in  more  detail. 
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Fig.  3-1  P  3G  Airborne  Patrol  System 


The  latest  event  in  the  airborne  ASW  digital  program  effort  is 
the  P-3C  update  wherein  a  drum  has  been  added  to  the  basic  P-3C  computer 
giving  it  a  seven- fold  increase  in  memory  capacity. 


3-2 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

Laurel.  Maryland 


Flight  Director 
Display 


Forward 

Radar 

Antenna 


To  Radar  Set 


I  Tactical 
'  Display 


Pilot 

Station 


Tactical 
Coord,  Station 
TACCO  Display 


Kevset  Arm  Copilot 

a0men|  Station 
Panel 


HF,  VHF, 
UHF 
Comm 


Omega 

P-3C 

(update) 


Data  Link 
4 ACQ-sl 


sNsr 


ASK-84 


AY  A -8  Converter  Group 


ASQ-114 

(CP-901) 

General 

Purpose 

Tactical 

Computer 


High 

Speed 

Printer 


Inertial 

Navigator 


(Future  IR) 

TUT]  f 

TV  ! 


APN-187  P0pple,r 
- - - Navigator 


]  Antenna 


72.  73A  SIF 


/Mag\ 
(Tape  ) 
VUnit/ 


1 

Z'  N  Drum  Memory 
<  )  (P-3C  Update) 

^  '  Future 

—  Capability 


ALQ-78 

F.CM 


— [  APS- 1 15 
Radar 
i  Video 


H 


To  Forward  Antenna 


Keyset 


i4  Keyset 

I _ 


Bathy 

Recorder 

Ambient 

Noise 

Meter 


To  Aft  Antenna 

Mad  Recorder 

ASQ- 

81 


AQA-7  ■ 

Acoustic 

Processor 


-  AQA-7 

Acoustic 
Stations 
1  and  2 


Non-Acoustic 
Sensor  Operator 
Station 


Sonobuoy 


ASQ-81 


Magnetometer 

Head 


u 

Sonobuoy 

Receiver 


i  Aft  Radar 
Antenna 


Fig.  3-2  P-3C  System  Block  Diagram 


3-3 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 
laurel  Maryland 


3.2  COMPUTER  SYSTEM  ARCHITECTURE 

3.2.1  Computer  Characteristics 

Table  3-1  gives  a  summary  of  the  computer  used  in  the  P-3C  Sys¬ 
tem. 


TABLE  3-1 

P-3C  COMPUTER  SUMMARY 


Unit 

Type 

Function 

Processor 

Memory 

Cl 

CP-901/ASQ-114 

Navigation,  storage  of 

1 

64k 

(30  bit,  2  ps) 

operator  entered  positions 
from  sensors,  sonobuoy 
tracking,  stores  inventory, 
stores  auto  drop  control, 
display  control 

3.2.2  Computer  Update 

The  P-3C  update  expands  the  tactical  computational  capability  of 
the  P-3C  by  the  addition  of  a  drum  memory.  The  drum  adds  393,000  words 
of  core  to  the  64,000  already  existing  in  the  CP-901  computer. 

3.2.3  Functional  Interfaces  with  Sensors 

In  general,  the  outputs  of  the  sensors  are  displayed  in  analog 
fashion  and  entered  into  the  data  processing  system  by  an  operator  via  a 
display  console  or  a  "keyset"  terminal.  The  exception  to  this  rule  is  a 
mode  of  operation  wherein  digital  outputs  from  the  acoustic  processor 
are  received  and  an  "automatic  detection"  function  is  performed.  The 
results  are  printed  on  the  high-speed  printer  to  alert  the  operators. 

The  acoustic  processor  used  in  conjunction  with  received  sono- 
buoy  signals  can  perform  narrowband  low-frequency  detection  and  record¬ 
ing  for  the  received  sonobuoy  signals.  The  types  of  sonobuoys  used  are 
both  passive  and  active.  Passive  capabilities  include  omni  and  direc¬ 
tional  signal  processing.  The  current  preprogrammed  pinging,  range-only 
active  buoy  processing  is  being  modified  to  include  a  commanded  pinging 
capability  as  well  as  multimode  frequency  operations.  Active  directional 
capability  will  be  provided  when  the  buoy  capability  is  introduced  to 
the  Fleet. 
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Acoustic  environmental  data  processing  units  include  a  recorder 
for  displaying  the  output  signals  from  an  expendable  bathythermograph 
sonobuoy  and  a  meter  for  monitoring  the  ocean  ambient  noise. 

The  nonacoustic  sensors  include  a  radar,  ECM  set,  Magnetic  Anom¬ 
aly  Detector  (MAD) ,  and  currently  a  Low  Light  Level  TV  (LLLTV) .  The 
LLLTV  is  being  replaced  with  an  infrared  system. 

3.3  COMPUTER  PROGRAM  ARCHITECTURE 

The  tasks  or  functions  performed  by  the  computer  fall  into  two 
major  categories:  (1)  tactical  or  operational,  and  (2)  pre-  and  in¬ 
flight  testing. 

3.3.1  Tactical  Program  Functions 

1.  Keeping  track  of  aircraft  position; 

2.  Storing  sonobuoy  positions  and  associated  target  bearings, 
ranges,  fixes,  and  track  vectors; 

3.  Storing  operator  inputs  of  Visual  Radar,  ECM,  and  MAD  target 
positions  and  track  vectors; 

A.  Performing  drift  correction  and  stabilization  computations 
for  sonobuoys; 

5.  Performing  acoustic  fixing  and  prediction  computations  for 
the  ASW  functions; 

6.  Computing  the  vector  commands  for  the  flight  director  system 
and  the  pilot's  display; 

7.  Keeping  track  of  loaded  and  expended  stores  of  sonobuoys 
and  weapons; 

8.  Comparing  aircraft  position  and  intended  drop  points  and 
automatically  releasing  stores  according  to  preprogrammed 
parameters ; 

9.  Accepting  inputs  from  pilot,  acoustic  operator,  and  naviga¬ 
tion  keysets  as  well  as  inputs  from  Tactical  Coordination 
Station  (TACCO)  and  Nonacoustic  Sensor  Operator  general- 
purpose  displays; 
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10.  Accepting  commands  from  the  ordnance  panel  and  TACCO  con¬ 
sole  and  initiating  launcher  drop  commands;  and 

31.  Processing  the  various  inputs,  grouping  data,  and  providing 
appropriate  display  symbology  for  the  TACCO  and  Nonacoustic 
Sensor  Displays. 

The  expanded  core  from  the  update  provides  room  to  perform  the 
following  functions: 

1.  Improved  Navigation  (worldwide  Omega  and  Transit); 

2.  Acoustic  and  ESM  classification; 

3.  Sonobuoy  Location  System  operations; 

4.  Tactical  satellite  communications; 

5.  Program  protection  and  degraded  mode  operations;  and 

6.  Tactical  Support  Center  briefing/debriefing  data. 

3.3.2  Testing  Program  Functions 

In  addition  to  the  operational  tasks,  the  computer  is  also  used 
to  perform  preflight  system  go-no-go  (SYGNOG)  operations.  In  this  mode 
the  operational  program  is  replaced  by  a  series  of  programs  that  per¬ 
forms  interface  as  well  as  larger  system  level  tests.  One  important 
feature  is  a  test  that  operates  in  conjunction  with  the  built-in  test 
equipment  of  the  AQA-7  acoustic  processor  to  determine  the  operability 
of  the  sonobuoy  receiver,  acoustic  processor,  and  recorder  subsystems 
operating  together.  The  results  from  the  entire  test  series  determine 
whether  or  not  the  aircraft  is  ready  to  perform  its  tactical  mission. 

If  not,  the  program  diagnostic  tests  are  used  to  assist  in  fault  loca¬ 
tion.  The  diagnostics  can  also  be  used  in  flight.  The  expanded  core 
from  the  update  provides  improved  system  test  operations  to  enhance  this 
capability. 


3.4  SOFTWARE  DEFINITION,  DESIGN,  AND  IMPLEMENTATION 

3.4.1  Software  Definition 

The  advent  of  nuclear,  high-performance  submarines  made  radar, 
visual,  and  ECM  detection  processes  secondary  to  acoustic  sonobuoy  de¬ 
tection  and  tracking.  In  addition,  acoustic  processing  techniques  were 
rapidly  advancing  toward  passive  direction-finding  as  well  as  active 
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buoy  capabilities.  The  classification  of  passive  submarine  signatures, 
though  conceptually  simple,  was  complex  from  the  total  number  of  features 
used  and  their  harmonic  relationships. 

Fortunately,  NADC  had  been  party  to  much  if  not  all  of  the  air¬ 
borne  acoustic  sensor  development  and  through  familiarity  with  the  prob¬ 
lem  were  able  to  recognize  what  needed  to  be  done  to  improve  the  situa¬ 
tion.  Their  experience  with  digitally  driven  displays  for  other  systems 
also  proved  helpful. 

As  stated  earlier,  development  at  NADC  started  around  1960, 
originally  involving  S-2  tactical  coordination.  The  work  was  then 
shifted  to  the  larger  P-3  airframe. 

Using  the  digital  program  in  hand  at  NADC,  the  Navy  began  the 
P-3C  program.  This  modification  to  the  P-3B  program  retained  the  basic 
types  of  sensors  but  included  new  versions  of  them.  The  contract  to 
Lockheed  started  out  initially  for  the  equipment  only,  with  the  Navy 
supplying  the  computer  program  under  NADC  auspices.  The  contract  then 
changed  to  include  provision  of  the  software  by  Lockheed. 

In  1968  Lockheed  received  the  NADC  FRS.  These  FRS  documents 
were  not  in  accordance  with  WS-8506  or  similar  standards.  They  were 
used  to  develop  coding  and  design  specifications. 

3.4.2  Software  Design 

The  computer  used  was  GFE  and  was  chosen  as  a  part  of  the  NADC 
Mod  3  effort.  It  represented  little  or  no  risk  in  the  context  that  it 
had  been  part  of  the  prototype  development. 

The  CS-1  language  and  compiler  were  also  GFE.  The  Executive 
program  is  basically  a  table  scanner,  and  some  redundant  code  exists  in 
the  program. 

From  an  overall  design  standpoint  and  realizing  that  the  basic 
program  operates  in  a  single  CPU  system,  the  design  is  straightforward. 

3.4.3  Software  Implementation 

The  creation  of  the  computer  program  by  Lockheed  became  largely 
one  of  redoing  the  functions  that  had  already  been  demonstrated  feasible 
by  virtue  of  having  the  NADC  prototype.  The  significance  of  this  was 
obviously  that  the  chance  of  achieving  success  was  high.  In  fact,  about 
20%  of  the  production  programmer  team  had  previously  been  on  the  NADC 
prototype  program. 
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A  significant  starting  point  for  the  P-3C  production  software 
occurred  when  Lockheed  received  the  contract  from  the  Navy.  The  equip¬ 
ment  with  which  the  already  specified  computer  was  to  interface  was 
government-selected  and  government-furnished.  In  order  to  digitally 
communicate  with  these  units  a  group  of  converters  and  logic  units  was 
necessary. 

The  computer  programming  started  with  the  operational  program 
and  was  followed  by  the  equipment  go-no-go  and  diagnostic  test  programs. 
Program  listings  themselves  provided  the  final  form  of  documentation. 

The  original  NADC  Mod  3  listings  were  used  as  references  during  the  pro¬ 
duction  software  development. 

Since  the  equipment  was  GFE,  the  documents  describing  the  equip¬ 
ment  operations  were  not  tailored  for  use  by  programmers.  Lockheed  in¬ 
stituted  a  Programmers  Technical  Manual  (PTM)  for  each  item  of  interest. 
These  PTM's  were  written  to  describe  the  equipment  operation  in  such  a 
way  that  a  programmer  would  understand  the  digital  input-output  inter¬ 
face  reactions. 


3.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

A  very  critical  part  of  the  acquisition  process  was  the  develop¬ 
ment  and  availability  of  the  Integration  Test  Facility,  which  preceded 
coding.  The  early  use  of  this  to  validate  code  was  considered  critical. 

This  test  facility  was  made  up  of  the  major  sensor,  display,  and 
computer  interfacing  equipment  as  well  as  the  computer  itself.  Code 
was  checked  out  in  segments  relating  to  individual  subsystems  and  then 
brought  together  into  a  total  system. 


3.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 


3.6.1  Overall  Management 

Program  Manager 
System  Contractor 
Type  Contract 

Software  Contractor 
Validation  Agent 
Maintenance  Agent 


PMA-240 

Lockheed  California  Co. 

Cost  plus  incentive  fee  (most 
equipment  GFE) 

Univac 

VX-1 

FCDSSA(DN)  (will  be  NADC  in  future) 
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Software  Deliverables  Operational  program,  system  test 

programs,  diagnostics,  functional 
requirements  specifications,  cod¬ 
ing  and  design  specifications, 
program  listings 

Integration  Agent  Lockheed  California  Co. 

A  Software  Management  Team  was  established  by  PMA-240  who  dele¬ 
gated  NAVAIR  533  to  be  chairmen.  The  remaining  team  members  were  Lock¬ 
heed,  Univac,  General  Electric,  NADC,  and  FCDSSA(DN) . 

Weekly  meetings  were  held  and  features,  improvements,  and  prob¬ 
lems  were  discussed.  Items  for  incorporation  or  change  were  given  pri¬ 
ority  based  on  criteria  that  included  whether  or  not  the  item  was  manda¬ 
tory  for  running  the  program  or  just  desirable,  its  cost  impact,  and  its 
schedule  impact.  A  steering  committee  vote  was  then  taken  to  designate 
appropriate  action  items. 

Periodic  design  reviews  were  held,  and  design  approaches  were 
validated  and  demonstrated  on  the  Integration  Test  Facility.  VX-1  ul¬ 
timately  conducted  an  OPEVAL. 

Standard  management  tools  were  used  by  Lockheed/Univac  in  the 
sense  that  persons  were  given  responsibility  and  test  demonstrations 
were  carried  out  at  progressive  levels  of  coding.  Problem  sheets  were 
generated,  and  appropriate  solutions  were  produced.  Frequent  recompiles 
were  made  to  keep  the  computer  up  to  date. 

3.6.2  New  Development  Management 

The  drum  P-3C  update,  previously  mentioned,  is  a  major  departure 
from  the  previous  procurement  of  software.  The  Navy  itself,  using  NADC, 
is  designing  and  developing  the  program.  The  extensive  Integration  Test 
Laboratory  at  NADC  has  provided  the  same  type  of  development  facility  as 
the  one  used  by  Lockheed.  This  step  was  taken  by  the  Navy  in  order  to 
achieve  an  alternative  to  sole  source  software  procurement. 

Operating  as  a  prime  contractor,  NADC  made  up  a  bid  package  for 
the  software  on  a  CPFF  basis.  Twenty  functional  specifications  were 
written,  and  the  program  compiler  chosen  was  the  CMS-2Q  (CMS-2  Version 
Q) .  Programs  are  debugged  on  a  batch  process  "desk  simulation"  as  well 
as  on  a  "hot  bench"  mockup  in  the  Integration  Test  Laboratory.  The  per¬ 
formance  of  the  system  is  monitored  at  the  Computer  Program  Design  Spec¬ 
ification  (CPDS)  level. 

NADC  has  followed  a  process  of  creating  the  program  in  levels  A 
through  G.  These  levels  culminate  in  about  500  programs  being  tied 
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together  to  accomplish  a  set  of  prespecified  tasks.  Testing  is  completed 
at  each  "build  level"  prior  to  creating  a  new  "build". 

The  program  itself  was  recompiled  about  every  5  weeks.  NADC 
considered  that  they  were  best  able  to  respond  to  change  while  the  pro¬ 
duct  was  being  built  by  following  this  build  level  approach. 


3.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

Upon  delivery  tc  the  Fleet,  FCDSSA(DN)  took  over  maintenance  sup¬ 
port  responsibility.  Eight  major  versions  of  the  program  have  evolved 
in  the  interim. 

Version  A  of  the  P-3C  program  was  delivered  by  Lockheed  in 
January  1969.  At  that  time,  when  first  delivery  was  being  made  to  an 
operational  squadron,  an  SCCB  was  formed.  In  parallel  with  this  a  Pro¬ 
duct  Improvement  Board  (PIB)  addressing  equipment  was  formed.  Again, 
through  the  use  of  the  Integration  Test  Facility,  corrections  and/or 
modifications  to  both  hardware  and  software  were  validated.  In  July 
1969  version  C  was  delivered  for  maintenance  and  modification  to 
FCDSSA(DN) .  Version  F  including  ESM  functions  was  also  delivered  by 
Lockheed.  From  then  on,  FCDSSA  has  developed  version  G  and  the  H  series 
(H.A,  H.B,  H.C,  and  H.D) ,  which  constitute  major  recompiles. 

Since  its  introduction  to  the  Fleet,  the  P-3C  program  has  been 
corrected  and  modified  using  the  following  procedure.  A  responsible 
coordinator  at  each  of  the  two  Fleet  Patrol  Wings  wherein  P-3C  aircraft 
are  assigned  is  given  the  task  of  soliciting  and  cataloging  inputs  from 
the  people  in  the  individual  patrol  squadrons.  Errors  discovered  in  the 
program  are  written  down  and  constitute  a  mandatory  "fix  list'  for 
FCDSSA.  Modifications  recommended  by  Fleet  personnel  are  considered  and 
listed  in  order  of  priority.  Some  are  rejected  by  the  SCCB  on  the  basis 
that  they  are  not  considered  useful  enough  to  warrant  the  change.  This 
list  is  then  passed  on  to  FCDSSA  who  then  combines  it  into  the  overall 
list  of  things  to  be  done  to  the  program. 

The  Fleet  ASW  System  Tester  (FAST)  is  a  computer  simulation 
facility  that  is  used  by  FCDSSA  to  make  changes  to  the  program.  After 
changes  are  made,  the  new  tape  is  carried  to  an  operational  unit,  and 
operability  is  verified  by  an  FCDSSA  representative. 


3.8  HIGHLIGHTS 

The  contract  to  Lockheed  was  originally  for  the  equipment  only, 
with  the  Navy  supplying  the  computer  program  under  NADC  auspices.  The 
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contract  was  subsequently  changed  to  include  provision  of  the  software 
by  Lockheed.  Lockheed's  task  then  was  to  redo  the  functions  already 
demonstrated  in  the  NADC  prototype.  About  20%  of  the  production  pro¬ 
grammer  team  had  previously  been  with  the  NADC  prototype  program. 

(MP1) 

The  GFE  computer  was  chosen  as  a  part  of  the  NADC  Mod  3  effort. 

It  represented  little  or  no  risk  since  it  had  been  part  of  the  prototype 
development.  The  selected  airborne  computer  was  chosen  as  the  constrain¬ 
ing  factor  in  program  size.  The  CS-1  compiler  was  also  GFE. 

(MP1,SE1,IP1) 

The  Functional  Requirements  Specifications  were  not  in  accordance 
with  WS-8506  or  similar  standards.  They  were  used  to  develop  coding  and 
design  specifications.  Program  listings  themselves  provided  the  final 
form  of  documentation.  The  original  Mod  3  NADC  listings  were  used  as 
references  during  the  production  software  development.  (MP3) 

Since  system  test  programs  actually  comprise  three  to  four  times 
as  much  code  as  the  operational  program,  they  should  be  given  proper 
attention  from  the  beginning  and  should  be  given  equal  priority  with 
the  operational  program.  (MP3) 

Based  on  the  experience  of  the  P-3C  software  development,  the 
digital  program  developers  indicate  the  need  for  a  more  structured  pro¬ 
gramming  approach  to  producing  the  final  product.  Along  with  this,  a 
need  was  recognized  for  a  "system  level"  document  that  would  address 
hardware  and  software  interactions  and  requirements  in  the  same  context. 
This  would  fill  the  gap  between  an  operational  level  specification  and 
the  program  functional  requirements  specification.  (SE1) 

The  original  computer  used  in  P-3C  had  32k  words  of  memory. 

During  development  the  computer  was  enlarged  internally  to  64k.  The 
recent  P-3C  "Update"  incorporated  a  384k  drum  to  perform  expanded  func¬ 
tional  capabilities.  System  test  programs  comprise  three  to  four  times 
as  much  code  as  the  operational  program.  (SE2) 

Since  the  equipment  was  GFE,  the  documents  describing  its  opera¬ 
tions  were  not  tailored  for  use  by  programmers.  Lockheed  instituted  a 
PTM  for  each  equipment  of  interest.  These  PTM's  were  written  so  that  a 
programmer  would  understand  the  digital  input-output  interface  reactions. 

(IP2) 

A  well-planned  integration  facility  should  be  allocated  from  the 
beginning.  Its  life  cycle  usage  for  program  maintenance  and  modifica¬ 
tion  can  help  amortize  its  cost.  (IP3) 

Thus,  a  very  critical  part  of  the  acquisition  process  was  the 
development  and  availability  of  the  Integration  Test  Facility  which 
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preceded  coding.  This  early  validation  of  code  was  considered  critical. 
The  test  facility  was  made  up  of  the  major  sensor,  display,  and  computer 
interfacing  equipment  as  well  as  the  computer  itself.  Code  was  checked 
out  in  segments  relating  to  individual  subsystems  and  then  brought  to¬ 
gether  into  a  total  system  representation.  (IP3) 

Production  level  management  of  software  requires  an  understand¬ 
ing  of  programming  at  the  coding  level  if  sound  decisions  are  to  be 
made.  (MSI) 

The  P-3C  update  is  a  major  departure  from  the  previous  procure¬ 
ment  of  software.  The  Navy  itself,  using  NADC,  is  designing  and  devel¬ 
oping  the  program.  The  extensive  Integration  Test  Laboratory  at  NADC 
has  provided  the  same  type  of  development  facility  as  the  one  used  by 
Lockheed.  This  step  was  taken  by  the  Navy  in  order  to  achieve  an  alter¬ 
native  to  sole  source  software  procurement.  (MS2) 

Involvement  of  the  life  cycle  software  support  agent  should  be 
instituted  at  an  early  stage.  His  involvement  can  include  being  part 
of  the  test  and  validation  team.  (MS3) 
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4.  S-3A  AIRBORNE  WEAPON  SYSTEM 


4.1  GENERAL  SYSTEM  DESCRIPTION 

The  S-3A  is  a  carrier-based  aircraft  with  the  mission  to  perform 
ocean  surveillance  for  convoy  and  strike  group  protection.  Detection, 
classification,  and  weapon  delivery  against  surface  and  subsurface  tar¬ 
gets  are  basic  requirements. 

The  system  is  capable  of  performing  operations  independently  or 
as  a  unit  in  a  coordinated  operation.  It  is  provided  with  communica¬ 
tions  and  data  link  equipment  to  allow  it  to  perform  the  coordinated 
operations.  Maximum  endurance  during  either  of  these  types  of  operation 
is  8  hours. 

Electromagnetic,  infrared,  and  acoustic  sensors  are  used  together 
with  the  visual  capabilities  of  the  crew. 

The  airframe  is  totally  new  and  designed  to  meet  the  requirements 
within  the  limits  of  aircraft  technology.  Two  turbofan  jet  engines  are 
of  special  design  to  meet  the  dash  and  loiter  speed  requirements. 

The  aircraft  system  includes  inertial,  doppler,  LORAN,  and  TACAN 
navigation  units.  The  data  processing  system  uses  this  and  other  tacti¬ 
cal  information  to  drive  commands  to  a  flight  director  system  for  use  by 
the  pilot. 

NTien  Lockheed  was  awarded  the  S-3A  contract  in  1969,  the  system 
experience  in  both  hardware  and  software  was  transferred  in  major  degree 
from  the  P-3C  effort.  The  major  increase  in  effort  was  in  acoustic  pro¬ 
cessing  and  classification,  and  in  associated  drum  storage  and  display 
requirements.  This  award  represented  the  culmination  of  the  NADC  ANEW 
program  that  was  started  in  1960.  Lockheed  subcontracted  to  Univac,  its 
bid  team  member,  for  the  software  on  a  fixed  price  basis.  An  Integra¬ 
tion  Test  Facility  was  established  at  the  outset  for  software/hardware 
interaction  development. 

Fleet  Issue  1,  the  first  Fleet  Operational  Program,  was  delivered 
in  1974.  Fleet  Issue  2,  delivered  in  February  1975,  is  comprised  of  er¬ 
rata  from  the  Board  of  Inspection  and  Survey  (BIS).  Fleet  Issue  3  will 
include  new  data  link  and  acoustic  classification  modifications.  Ten  op¬ 
erational  squadrons  will  be  outfitted  with  the  new  system  by  1977. 

Figure  4-1  shows  a  schematic  of  the  S-3A  system.  Figure  4-2 
shows  the  S-3A  system  block  diagram  in  more  detail  (excerpted  from  the 
Lockheed  S-3A  Avionics  Weapon  System  Functional  Description  -  LR  23666). 


Fig.  4-2  S-3A  System  Block  Diagram 
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4.2  COMPUTER  SYSTEM  ARCHITECTURE 

4.2.1  Computer  Characteristics 

Table  4-1  gives  a  summary  of  the  computer  used  in  the  S-3A  sys¬ 
tem. 


TABLE  4-1 

S-3A  COMPUTER  SUMMARY 


Unit 

Type 

Function 

Processor 

Memory 

Cl  &  C2 

U  1832 
(32  bit  +  4 
parity,  1.5  ys) 
AYK-10 

Navigation,  Harpoon 
launch  control,  target 
tracking,  sonobuoy 
tracking  and  inventory, 
target  classification, 
INCOS  control,  display 
control,  system  tests 

2 

(multiprc- 

cessed) 

64k 

The  AYK-10  computer  includes  two  memory  drums  totaling  about 
180k  words.  The  CPU  is  an  independent  dual  processor  very  similar  in 
operation  to  the  UYK-7. 

4.2.2  Functional  Interfaces  with  Sensors,  Displays,  and  Flight  Director 
System 

The  acoustic  processor  used  in  conjunction  with  reveived  sonobuoy 
signals  cau  perform  narrowband  low-frequency  detection  and  recording  for 
the  received  sonobuoy  signals.  The  types  of  sonobuoys  used  are  both 
passive  and  active.  Passive  capabilities  include  omni  and  directional 
signal  processing.  The  current  preprogrammed  pinging,  range-only  active 
buoy  processing  is  being',  modified  to  include  a  commanded  pinging  capabil¬ 
ity  as  well  as  multimode  frequency  operations.  Active  directional  capa¬ 
bility  will  be  provided  when  the  buoy  capability  is  introduced  to  the 
Fleet. 


Acoustic  environmental  data  units  include  processing  for  the  out¬ 
put  singals  from  an  expendable  bathythermograph  sonobuoy  and  a  measure¬ 
ment  of  the  ocean  ambient  noise. 

The  nonacoustic  sensors  include  a  radar,  ESM  set,  Magnetic  Anom¬ 
aly  Detector  (MAD) ,  and  Forward  Looking  Infrared  (FLIR) . 
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The  sensor  outputs  and  tactical  symbology  generated  by  the  com¬ 
puter  are  displayed  for  the  two  operator  and  the  pilot  and  copilot  sta¬ 
tions  directly  on  the  multipurpose  display  (MPD) .  Additionally,  the 
computer  generates  driving  signals  for  the  flight  director  system  used 
by  the  pilot  and  copilot.  The  digital  program  itself  is  loaded  and  con¬ 
trolled  via  the  Integrated  Control  System  (INCOS),  which  is  part  of  the 
operator's  console  and,  once  loaded,  responds  to  automatic  inputs  from 
the  peripheral  equipment.  Unlike  former  airborne  ASW  systems  wherein 
the  sensors'  block  boxes  were  used  separately  to  provide  data,  sensors 
are  more  closely  integrated  into  the  combat  information  systems. 


4.3  COMPUTER  PROGRAM  ARCHITECTURE 

The  Executive  program  chosen  was  an  1108  derivative  streamlined 
to  keep  down  the  core  and  time  overhead.  The  operational  program  is 
made  up  of  18  functionally  oriented  modules.  There  are  30k  words  used 
for  transient  data,  and  150k  are  allocated  to  instructions  and  data. 

10k  words  (core  and  drum)  are  reserved  as  spare.  Only  64k  of  this  capa¬ 
bility  is  resident  in  the  mainframe  computer  memory. 

Some  of  the  code  is  ULTRA- 32  that  is  generated  on  a  UYK-7.  A 
642-B  computer  hosting  the  XCMS-2  compiler  generates  XCMS-2  code.  A 
system  generator  operating  on  the  UYK-7  combines  the  XCMS-2  and  ULTRA- 
32  codes. 

The  acoustic  data  processing  system  bears  special  mention  since 
three-quarters  of  each  drum  is  used.  A  separate  computer  (8k  MOS)  is 
used  to  interchange  the  data  and  is  part  of  the  (Sanders)  Acoustic  Data 
Processor. 

A  data  extraction  program  has  been  inserted  as  a  common  service 
subroutine  throughout  the  program. 

4.3.1  Tactical  Program  Functions 

When  loaded  with  the  operational  program,  the  computer  performs 
the  following  basic  operational  tasks: 

1.  Keeping  track  of  aircraft  position  as  a  function  of  naviga¬ 
tional  inputs; 

2.  Storing  initial  sonobuoy  positions  and  associated  target 
hearings,  ranges,  fixes,  and  track  vectors; 

3.  Updating  sonobuoy  positions  with  the  processed  Sonobuoy  Lo¬ 
cation  System  inputs; 
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4.  Storing  operator  inputs  of  visual,  radar,  ECM,  and  MAD 
target  positions  and  track  vectors; 

5.  Performing  drift  correction  and  stabilization  computations 
for  sonobuoys; 

6.  Performing  acoustic  fixing  and  prediction  computations  for 
the  ASW  functions; 

7.  Comparing  the  detected  input  acoustic  signatures  with  a 
classification  table; 

8.  Computing  the  vector  commands  for  the  flight  director  system 
and  the  pilot's  display; 

9.  Keeping  track  of  loaded  and  expended  stores  of  sonobuoys 
and  weapons ; 

10.  Comparing  aircraft  position  and  intended  drop  points  and 
automatically  releasing  stores  according  to  preprogrammed 
parameters; 

11.  Accepting  operator  inputs  from  the  INCOS  keysets; 

12.  Accepting  commands  from  the  stores  panel  and  generating 
launcher  drop  commands;  and 

13.  Processing  the  various  inputs,  grouping  data,  and  providing 
appropriate  display  symbology  for  the  General  Purpose  Dis¬ 
plays.  This  includes  sensor  data  as  well  as  tactical  sym¬ 
bology  for  radar,  FLIR,  ESM,  MAD,  and  sonobuoys. 

4.3.2  Nontactical  Program  Functions 

In  addition  to  the  foregoing  operational  tasks,  the  computer  is 
also  used  to  perform  preflight  and  inflight  system  go-no-go  and  diag¬ 
nostic  operations.  In  this  mode  the  operational  program  is  replaced  by 
a  series  of  programs  that  performs  interface  as  well  as  larger  system 
level  tests.  One  important  feature  is  that  programmed  tests  can  request 
that  any  piece  of  equipment  perform  a  built-in  test  to  provide  amplifying 
data  on  a  malfunctioning  device.  The  results  obtained  from  the  entire 
test  series  are  critical  in  determining  whether  or  not  the  aircraft  is 
ready  to  perform  its  tactical  mission.  If  not,  the  program  diagnostic 
tests  are  used  to  assist  in  fault  location. 

An  additional  set  of  programs  is  available  to  the  S-3A  for  train¬ 
ing,  mission  analysis,  and  premission  preparation.  These  programs  are 
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-a  r^mrtrie  the  functions  im- 
part  Of  the  weapon  System  Support  Programs  and  prov 

plied  by  their  titles. 


SOFTWARE 


DEFINITION ,  DESIGN,  AND  IMPLEMENTATION 


441  Software  Definition  f, 

4  n  ,  a  »  hiEh-level  functional  specif ica 

The  Navy's  contract  Included  ah^  ^  ^  expUcltly  to. :^t 

tion  with  performance  stated  *  Lockheed  produced  b 

SS£sTi£S?: 

STSS;  rgetrtin°gteivac  to  develop  the  program. 

442  Software  Design  .  d 

4  4*j„Mnns  for  equipment  existed 

As  in  the  P-3C  experience,  spec  for  programmer  usage.  Appen 

faces  with  the  computer. 

Descriptions  (EFFD  s  .  „ritten  by  Lockheed,  Univac 

From  the  F“nct ^"f^ci^Computer  Programming  P«F°E““e 
was  required  to  respond  by  closely  resembled  that  o  ac_ 

Review^and^revisions^  of  these  CPFS  =  ~ “Sit  Specifica- 

re^D^rrt.p"SjlSL  were  written  by  Dnlvac. 
tlons  (CPDS)  ana  „ere  inserted 

The  initial  Jeaign  prom  that  point  "Software 

wer^  formally  invoked. 


4,4.3  Software  Implementation 

t  4Ht-v  used  to  produce  the  S  3A 
The  primary  implementation  facil  y  iUt  (sdF)  .  The  SDF 

programs  was  the  Univac  Software  Deve^opmen  ^  computer  suite  for  gen- 

StSed “raUUtrofth^^^generation  facility  ^greatly 

Trkcilit,  (ITF)  and  iterated 

back  through  as  modifications. 


4-7 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

Laurel  Maryland 


4.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

Every  6  weeks  the  Operational  Program  was  checked  out  at  three 
levels:  module,  multimodule,  and  scenario.  The  scenario  level  refers 
to  a  set  of  operations  whose  sequence  follows  a  typical  tactical  problem. 

The  ITF  contains  an  Integrated  Bench  Facility  (IBF)  for  computer 
interfacing  of  specific  pieces  of  equipment  and  performance  of  end-around 
testing  through  use  of  a  patch  panel  that  connected  into  the  larger,  more 
complex  suite  of  S-3A  equipment  and  sensor  simulators  in  the  ITF.  This 
IBF  includes  test  equipment,  bench  test  harnesses,  a  1230  computer  com¬ 
plex,  and  associated  special  test  software.  The  ITF  also  includes  a  hot 
avionics  mockup  for  software  and  hardware  integration  and  debugging. 

During  1969  to  1974  about  175  programmers  were  used  to  generate 
500,000  instructions.  Roughly  one-third  of  the  effort  was  used  to  gen¬ 
erate  the  operational  program.  Two-thirds  was  used  to  generate  the  sys¬ 
tem's  test  and  diagnostics  as  w^ll  as  the  special  development  test  soft¬ 
ware  . 


4.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 


Program  Status 
Program  Manager 
System  Contractor 
Type  Contract 

Software  Contractor 


OPEVAL 

PMA-244 

Lockheed  California  Co. 


Cost  plus  incentive  fee  (most  equip¬ 
ment  CFE) 

Univac 


Validation  Agent  VX-1 


Maintenance  Agent 
Software  Deliverables 


Integration  Agent 


NADC 

Operational  Program,  system  test 
programs,  diagnostics,  functional 
requirements  specifications,  cod¬ 
ing  and  design  specifications, 
program  listings 

Lockheed  California  Co. 


The  S-3A  system  was  procured  by  the  Navy  on  the  basis  of  the 
"milestone"  concept,  meaning  that  the  S-3A  had  to  pass  specified  criteria 
at  selected  points  in  its  development,  both  as  to  cost  and  technical  pro¬ 
ficiency.  The  software  as  well  as  most  of  the  equipment  was  contracted 
for  as  Contractor  Furnished  Equipment  (CFE) . 
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From  the  beginning,  a  Lockheed/Univac  team  concept  was  estab¬ 
lished  and  pursued  in  order  to  minimize  formal  documentation  require¬ 
ments.  This  was  considered  effective  on  the  basis  that  the  program¬ 
mers  had  a  fundamental  familiarity  with  the  problem  and  associated 
equipment  types  from  the  P-3C  effort. 

Lockheed  did  not  actively  use  the  CPDS  and  subprogram  specifica¬ 
tions  written  by  Univac  to  track  the  program,  although  they  recognized 
that  this  level  of  documentation  would  be  needed  eventually  by  the  main¬ 
tenance  support  activity.  Instead,  Lockheed  maintained  progress  checks 
through  functions  (i.e.,  the  status  of  functions  being  produce  against 
a  milestone  chart).  These  were  checked  weekly,  and  the  entire  process 
was  thought  to  minimize  documentation  among  the  working  team.  The  or¬ 
ganizational  structure  was  set  up  such  that  a  Site  Manager  was  in  charge. 
He  in  turn  had  Project  Engineers  (Line  Supervisors)  for  the  four  major 
areas : 

1.  Operational  Program, 

2.  System  Test, 

3.  Support  Software,  and 

4.  Integration  Group. 

The  further  breakdown  within  the  Operational  Program,  for  exam¬ 
ple,  included: 

1.  Executive  Program  Supervisor, 

2.  Acoustic  Supervisor,  and 

3.  Nonacoustic  Supervisor. 

Group  leaders  within  each  of  these  major  functional  areas  were 
assigned  with  supporting  programmers  and  worked  on  one  to  two  modules 
as  a  team. 

The  initial  design  was  iterated  as  modifications  were  inserted 
until  such  Lime  as  the  design  was  frozen.  From  that  point  "Software 
Change  Notices"  were  formally  invoked. 


4.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

Fleet  Issue  1  (FI-1)  (which  included  fault  isolation  functional 
tests)  was  the  major  initial  program  issued  for  introduction  to  the 
Fleet.  At  that  point  (1974),  the  Navy  instituted  a  "change  proposal" 
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process  for  the  BIS,  NPE,  NPA,  and  OPEVAL  process  bv  NATC  and  COMOPTEV- 
FOR  (VX-1).  A  SCCB  was  chaired  by  PMA-244 .  The  software  support  func¬ 
tion  is  presently  being  carried  out  at  Lockheed  as  a  level  of  effort 
contract.  FI-2  was  done  to  perform  errata  discovered  in  BIS.  FI-3  con 
tains  a  new  data  link  module  and  a  modification  to  the  acoustic  classi¬ 
fication  module. 


4.8  HIGHLIGHTS 

When  Lockheed  was  awarded  the  S-3A  contract,  much  of  the  system 
experience  in  both  hardware  and  software  was  transferred  from  the  P-3C 
efforts.  The  major  increase  in  effort  was  in  acoustic  processing  and 
classification,  and  associated  drum  storage  and  display  requirements. 

The  Performance  Specification  was  written  as  a  joint  effort  between  the 
integration  contractor  (Lockheed)  and  the  software  contractor  to  ensure 
thorough  mutual  understanding.  The  contract  for  the  software  was  fixed 
price.  (MP1,MP3) 

Although  documentation  was  minimized  in  tracking  the  functional 
development  in  preference  to  using  listings  and  code,  this  required  a 
one-on-one  personnel  requirement.  This  also  resulted  in  a  lack  of  cross 
informational  exchange  and  lack  of  documentation  for  "add-on"  programs, 

etc.  <MP3) 

Flow  charts  were  automatically  generated  from  source  tapes  but 
were  not  used  in  this  program.  (MPJ) 

During  1969-1974,  about  175  programmers  generated  500,000  in¬ 
structions.  Roughly  a  third  of  the  effort  was  used  to  generate  the  oper¬ 
ational  program.  The  rest  was  used  to  generate  the  system's  test  and 
diagnostics  and  the  special  development  test  software.  (MP3) 

The  S-3A  management  of  software  included  milestones  listed  for 
each  primary  "function."  The  programs  were  constructed  with  a  building 
block  concept  that  determined  where  milestones  were  logically  sequenced. 
Standard  Milestones  and  Weekly  Progress  Reviews  were  used  for  ovrr  800 
separate  functions.  (API) 

Frequent  module  level  recompiles  (daily  or  weekly)  are  considered 
important  in  tracking  programmer  modifications.  (AP2,IP1) 

Allowing  the  test  people  to  use  their  own  executive  and  input- 
output  control  methods  instead  of  those  of  the  operational  program  re¬ 
sulted  in  redundant  operations  and  1/0  testing  not  entirely  representa¬ 
tive  of  system  operation.  (SE1,SE3,IP1,IP3) 
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A  team  concept  was  used  in  development,  which  required  that  the 
Design  Engineer  and  Programmer  worked  together  daily  and  that  the  engi¬ 
neer  understand  programming  language.  ( IP2 ) 

A  comprehensive  integration  and  test  support  facility  was  devel¬ 
oped  for  the  S-3A  development.  Program  checkout  and  a  phased  sequence 
of  integration  steps  were  accomplished  using  this  facility.  The  facil¬ 
ity,  which  used  both  actual  and  simulated  equipment,  minimized  the  need 
for  flight  tests  to  verify  system  performance.  A  flying  test  bed  was 
required  for  final  integration  and  testing.  (IP3) 

Not  enough  preliminary  development  effort  was  addressed  to  oper¬ 
ator  logic,  needs,  and  operations.  This  suggests  an  operator/missions 
studv  and  simulation  effort  prior  to  production  for  any  future  programs. 

(MS3) 
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5.  F-14  AVIONICS  AND  WEAPON  DELIVERY  SYSTEM 


5.1  GENERAL  SYSTEM  DESCRIPTION 

The  F-14  Tomcat  Is  a  high-perf  orm.'.nce  carrier-based  fighter  in¬ 
terceptor  that  is  the  platform  for  the  F-14  Avionics  and  Weapon  Delivery 
System. 

The  primary  mission  of  the  total  F-14/Phoenix  System  is: 

(a)  Fleet  Air  Defense,  (b)  Air  Superiority  —  both  Beachhead  and  Escort, 
(c)  Air  Combat  Maneuvers,  and  (d)  Interdiction. 

In  support  of  its  stated  mission  objectives,  the  F-14  Avionics 
and  Weapon  Delivery  System  has  the  capability  of: 

1.  Detecting  and  tracking  high-altitude  targets  at  long  range, 
using  pulse  doppler  search  (PDS)  and  single  target  track 
(STT)  modes; 

2.  Detecting  high-altitude  hot  targets  against  a  cool  sky  with 
the  passive  infrared  search  and  acquisition  sensor; 

3.  Maintaining  24  simultaneous  sensor  target  tracks  using  the 
track-while-scan  (TWS)  mode; 

4.  Maintaining  eight  simultaneous  data  link  (Link  4A)  tracks; 

5.  Looking  down  for  detecting  and  tracking  low-altitude  targets 

6.  Engaging  maneuvering  targets  in  close-in  "dogfights"; 

7.  Engaging  up  to  six  separate  targets  simultaneously  with  the 
very  long  range  AIM-54A  (Phoenix)  missiles;  and 

8.  Using  all  other  Navy  air-to-air  and  air-to-ground  weapons. 

The  major  components  of  the  F-14  system,  other  than  the  airframe 
itself,  are  the  Sensor  System,  the  Weapon  System,  AWG-9  Weapon  Control 
System,  and  the  Computer  Signal  Data  Converter  (CSDC)  Subsystem.  Figure 
5-1  is  a  block  diagram  of  the  F-14  Avionics  and  Weapon  Delivery  System. 

5.1.1  Sensor  System 

The  main  F-14  sensors  are:  (a)  a  long-range  radar,  (b)  a  high- 
resolution  infrared  system,  and  (c)  an  IFF  unit.  Sensors  (a)  and  (b) 
are  part  of  the  AWG-9  Weapon  Control  System  (WCS) . 
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5.1.2  Weapon  System 

The  armament  of  the  F-14  aircraft  is  a  mixture  of  the  following: 

1.  Phoenix  (AxM-54A)  long-range  missiles  (up  to  six); 

2.  Sparrow  (AIM-7E/F)  short-range  missiles  (up  to  six,  or  a 
mix  of  Phoenix  and  Sparrow) ; 

3.  Sidewinder  (AIM-9G/H)  heat-seeking  missiles  (up  to  four); 

4.  Vulcan  (M-61)  high-rate-of-f ire  20-mm  cannon;  and 

5.  Air-to-ground  stores  (bombs). 

5.1.3  AWG-9  Weapon  Control  System 

The  AWG-9  System  is  a  Weapon  Control  System  containing  two  major 
sensors  —  a  pulse  doppler  search/track/acquisition/guidance  radar  and 
the  gimbal-mounted  infrared  search/acquisition  sensor.  It  includes  the 
CDC  5400B  high-speed  digital  computer,  the  Tactical  Information  Display 
(TID)  ,  the  Detail  Data  Display  (DDD) ,  and  various  controls  for  the  Naval 
Flight  Officer  (NFO) ,  seated  in  the  second  of  the  F-14's  tandem  seats, 
to  operate  the  AWG-9  and  launch  the  aircraft's  radar  missiles. 

All  targets  are  shown  symbolically  on  the  TID.  They  are  identi¬ 
fied  as  friendly  or  hostile,  either  by  the  aircraft's  radar/IFF  (maxi¬ 
mum  of  24)  or  from  data  relayed  to  the  aircraft  via  Link  4A  (maximum  of 
8).  In  addition  to  location  and  identification,  target  altitude  and 
course  are  indicated.  The  NFO  can  monitor  the  DDD  to  be  certain  the 
computer  is  tracking  all  targets  or  to  help  pick  out  targets  using  ECM. 
The  pilot  has  a  repeat  of  the  computer-generated  target  data  coupled 
into  his  horizontal  situation  display. 

With  the  two  displays,  the  NFO  is  prepared  to  fire  all  weapons, 
other  than  the  cannon  and  Sidewinders,  especially  against  long-range 
targets.  The  pilot  can  fire  any  of  the  aircraft's  weapons. 

The  AWG-9  has  extensive  built-in  test  (BIT)  features  that  can 
isolate  a  malfunction  to  one  of  the  30  boxes  comprising  the  system, 
identify  the  decision  point  where  the  failure  occurred,  and  advise  the 
crew  of  the  surviving  operable  AWG-9  modes. 

5.1.4  CSDC  Subsystem 

The  CSDC  Subsystem  performs  the  aircraft's  navigation  functions; 
provides  the  stabilization  interface  to  the  radar,  infrared,  and  missile 
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auxiliary  equipment;  and  handles  data  flow  to  the  avionic  equipment.  It 
includes  a  Teledyne  Systems  CP-1050  high-speed  digital  computer  and  a 
multipurpose  converter  device, 

In  performing  the  navigation  computations,  the  CSDC  accepts  in¬ 
cremental  velocity  pulses  from  the  Inertial  Measurement  Unit  (IMU)  and 
solves  the  pure  inertial  equations.  Backup  navigation  using  the  Air  Data 
Computer  (ADC)  and/or  the  Altitude  and  Heading  Reference  System  (AHRS)  is 
automatically  provided  if  the  IMU  fails. 

The  CSDC  also  performs  extensive  onboard  checkout  (OBC)  of  the 
avionics  equipment,  interfaces  with  and  provides  data  to  the  AWG-9  com¬ 
puter,  and  drives  the  pilot's  Multiple  Display  Indicator  Group  (MDIG) 
and  Vertical  Display  Indicator  Group  (VDIG) . 

5.1.5  Acquisition  History 

The  Navy  announced  that  it  had  awarded  a  contract  to  Grumman  in 
January  1969  for  a  new  carrier-based  fighter  for  the  U.S.  Navy.  Known 
as  the  VFX  during  the  competition  phase  of  the  program,  this  aircraft 
was  officially  designated  the  F-14  Tomcat. 

First  flight  test  of  the  F-14A  prototype  took  place  on  21  Decem¬ 
ber  1970;  seven  more  F-14A's  were  flying  before  the  end  of  1971,  and  by 
early  1973,  20  aircraft  had  logged  almost  3000  hours  in  more  than  1500 
flights.  Weapons  System  testing  accounted  for  half  of  the  total  flight 
time. 


The  AWG-9/Phoenix  concept  was  initiated  in  1960  and  Hughes  Air¬ 
craft  Co.  (HAC)  was  selected  as  the  prime  contractor  by  the  Navy  in  1962. 
Flight  testing  began  in  1965,  and  the  first  successful  intercept  was  in 
September  1966.  The  simultaneous  attack  capability  was  demonstrated  in 
March  1969  when  two  drones  were  engaged  from  an  F-111B  aircraft.  Subse¬ 
quent  to  cancellation  of  the  F-111B,  development  of  Phoenix  has  been  in 
relation  to  the  F-14  aircraft.  F-14  flight  trials  started  in  April 
1972,  and  in  December  1972  four  jet  drone  targets  were  successfully  en¬ 
gaged  by  four  Phoenix  missiles  launched  and  directed  by  the  AWG-9  Sys¬ 
tem  of  an  F-14A  Tomcat. 


5.2  COMPUTER  SYSTEM  ARCHITECTURE 

The  F-14  aircraft  uses  two  general-purpose  computers.  The  AWG-9 
computer  is  used  within  the  AWG-9  Weapon  Control  System  to  perform  tar¬ 
get  tracking,  steering,  display,  computation  of  missile  launch  zones  and 
parameters,  navigation,  and  BIT  processing.  The  other  general-purpose 


5-4 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

LAUREL,  MARYUNO 


computer,  the  CSDC,  is  used  to  perform  computations  for  platform  manage¬ 
ment,  coordinate  transformation,  and  onboard  checkout.  The  use  of  these 
two  computers  in  relationship  to  the  F-14  system  interfaces  is  shown  in 
Fig.  5-1.  A  summary  of  the  two  computers  is  shown  in  Table  5-1. 


TABLE  5-1 

F-14  COMPUTER  SUMMARY 


Unit 

Type 

Function 

Processor 

Memory 

Cl 

CDC  5400B 
(AWG-9) 

(24  bit,  1  ys) 

Target  tracking,  steer¬ 
ing,  display,  missile 
launch  zones  and  parame¬ 
ters,  navigation,  BIT 

1 

24k  NDRO 
8k  DRO 
140k  Tape 

C2 

Teledyne  Systems 

CP-1050 

(CSDC) 

(20  bit,  7.5  ys) 

Platform  management, 
coordinate  transforma¬ 
tions,  avionics  input/ 
output,  OBC 

1 

lk  NDRO 
4k  DRO 

5.2.1  AWG-9  Computer  Subsystem 

The  AWG-9  computer  is  a  fixed  point,  twos  complement,  parallel, 
programmable  general-purpose  processor.  A  24  bit  word  length  is  used 
although  data  may  be  accessed  in  half-word  segments.  The  instruction 
list  includes  64  whole-  and  half-word  instructions,  including  multiply, 
divide,  square  root,  and  search  instructions.  The  memory  includes  24k 
of  Non-Destructive  Read  Out  (NDRO)  and  8k  of  Destructive  Read  Out  (DRO) . 
The  24k  memory  may  be  loaded  using  the  AWM-23  Fleet  support  equipment 
but  cannot  be  altered  during  the  flight  of  the  F-14.  Special  engineer¬ 
ing  test  equipment  is  used  in  the  test  community  for  memory  load,  but  it 
is  not  used  in  the  Fleet.  The  AWM-23  provides  this  function  for  the 
Fleet.  The  8k  memory,  however,  is  used  for  dynamic  data  and  programs 
loaded  from  magnetic  tape.  The  memory  cycle  time  is  1  ys,  which  is  also 
the  add  and  subtract  time.  Multiply  or  divide  instructions  require  11 
ys.  The  central  processor  is  designed  to  compute  in  fractional  notation 
in  which  the  binary  point  is  to  the  left  of  the  most  significant  bit, 
rather  than  to  the  right  of  the  least  significant  bit.  A  magnetic  tape 
unit  built  into  the  AWG-9  computer  has  a  capacity  of  140k  words.  Simi¬ 
larly  to  the  NDRO  memory,  the  tape  is  loaded  using  the  AWM-23  Fleet  sup¬ 
port  equipment  and  cannot  be  modified  during  F-14  flights. 
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The  AWG-9  Computer  Interface  Unit  (IFU)  has  an  extensive  capa¬ 
bility  for  interfacing  with  a  variety  of  F-14  devices.  The  central  pro¬ 
cessor  interface  is  a  parallel  Direct  Memory  Access  (DMA)  channel  to  and 
from  DRO  memory  under  IFU  control.  In  addition,  a  parallel  channel  to 
and  from  the  central  processor  accumulator  is  available  under  program 
control.  Serial  interfaces  include  a  10-channel  AWG-9  standard  serial 
interface,  a  1-char.nel  data  link  interface,  and  a  1-channel  high  PRF  mis¬ 
sile  message  interface.  An  Analog  Digital  Analog  (ADA)  converter  permits 
35  analog  inputs  and  35  analog  outputs  to  interface  with  the  AWG-9  com¬ 
puter.  Parallel  digital  interfaces  include  44  digital  inputs  and  36  digi¬ 
tal  outputs.  The  IFU  also  includes  special  features  for  VCO  frequency 
measurement,  NFO  display  interface,  and  doppler  data  conversion. 

The  AWG-9  computer  is  a  Control  Data  Corporation  (CDC)  5400B 
computer  that  was  evolved  for  the  AWG-9  from  the  CDC  5400A.  During  the 
F-lll  development,  a  fly-off  program  for  the  computer  subsystem  led  to 
proposals  by  Honeywell,  CDC,  and  Univac  and  eventual  contract  award  to 
CDC.  Procurement  was  driven  largely  by  the  requirement  for  rapid  devel¬ 
opment,  which  could  be  most  easily  accommodated  by  evolution  of  the  CDC 
5400A  computer.  When  the  AWG-9  system  switched  from  the  F-lll  to  the 
F-14,  a  faster  version  of  the  5400A  was  developed. 

The  design  approach  of  the  AWG-9  computer  subsystem  was  affected 
in  other  ways  by  the  requirement  for  rapid  system  development.  Because 
of  the  tight  time  constraints  in  F-14  development,  an  advanced  develop¬ 
ment  model  or  engineering  development  model  could  not  be  utilized  to  ob¬ 
tain  firm  design  of  the  subsystems.  In  order  to  minimize  hardware 
changes  after  deployment  of  the  initial  F-14  systems,  the  design  approach 
for  the  computer  subsystem  emphasized  flexibility  and  growth  features. 

The  incorporation  of  traditional  radar  and  system  logic  functions  within 
the  computer  subsystem  permits  design  change  by  the  modification  of  com¬ 
puter  programs.  Also  many  interfaces  were  designed  to  be  fully  program¬ 
mable  to  maximize  flexibility  in  interfacing  with  other  subsystems.  Im¬ 
plementation  of  functions  in  the  computer  subsystem  was  also  performed, 
where  possible,  to  minimize  hardware  development.  This  has  led  to  ex¬ 
panded  interaction  in  control  of  the  system  hardware  functions  by  the 
computer  subsystem.  Radar  control  loops  are  closed  through  the  computer 
subsystem,  resulting  in  a  requirement  for  highly  efficient  and  responsive 
computer  software,  design.  To  improve  computer  processing  resources,  the 
memory  cycle  time  was  shortened,  processor  logic  was  speeded  up,  and  the 
DMA  interface  channel  was  expanded. 

Reliability  figures  for  the  computer  subsystem  have  been  obtained 
from  operations  at  NAS  Miramar  and  the  USS  Enterprise.  Of  the  22  hr  MTBF 
required  of  the  AWG-9  system,  12%  is  allocated  to  the  computer  subsystem 
(equivalent  to  184  hr).  In  about  2000  hours  of  operations  at  NAS  Mira¬ 
mar,  the  computer  subsystem  experienced  494  hr  of  MTBF,  which  is  265%  of 
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the  objective.  In  about  2000  hours  of  operations  from  the  USS  Enter¬ 
prise  a  113-hr  MTBF  or  62%  of  the  objective  was  obtained  for  the  com¬ 
puter  subsystem.  However,  about  50%  of  the  failures  were  associated 
with  the  single  component  type  in  the  computer  interface  hardware  con¬ 
version  (A/D  and  D/A)  unit. 

5.2.2  CSDC  Computer  Subsystem 

The  Computer  Signal  Data  Converter  (CSDC) ,  developed  by  Grumman 
Aerospace  Corporation,  includes  a  number  of  I/O  conversion  interface 
modules  and  a  GP  computer  as  shown  in  Fig.  5-2.  The  CP-1050  computer, 
procured  under  contract  to  Teledyne  Systems,  was  evolved  from  a  com¬ 
puter  used  in  previous  systems.  The  processor  has  an  add  time  of  about 
7  ps  and  a  multiply  time  of  31  ps.  A  20  bit  word  length  is  used  with  a 
4k  DRO  memory  and  a  lk  NDRO  memory. 

To  initially  select  a  signal  data  converter  unit,  requirements 
were  defined  and  proposals  obtained,  all  but  one  of  which  specified 
electromechanical  devices.  The  Teledyne  proposal  included  a  GP  computer 
and  was  selected  based  on  a  combination  of  cost,  volume,  MTBF,  and 
growth  potential. 

The  CSDC  performs  primary  navigation  including  platform  mainten¬ 
ance,  avionics  on-board  checkout,  converter  and  conversion  functions, 
central  interface  for  all  avionics,  partial  display  interface,  data  link 
interface,  and  platform  alignment. 


5.3  COMPUTER  PROGRAM  ARCHITECTURE 
5.3.1  AWG-9  Program  Architecture 

To  implement  its  assigned  functions,  a  program  architecture  has 
been  established  specifically  for  the  AWG-9  Weapon  Control  System  with 
strong  consideration  for  efficiency  of  memory  and  time  utilization.  As 
mentioned  in  Section  5.2.,  the  AWG-9  computer  is  highly  involved  in  the 
radar  control  loop  requiring  efficient  and  responsive  program  execution. 
The  program  is  entirely  interrupt-driven  eliminating  the  need  for  any 
general-purpose  scheduling  with  the  Executive.  The  program  is  not  modu¬ 
lar,  but  rather  contains  a  series  of  over  100  routines  that  are  executed 
in  particular  sequences  for  each  function  required.  The  routines  for 
each  function  are  indicated  in  Fig.  5-3. 

Basic  timing  for  the  program  interrupts  is  generated  from  an  8 
ms  radar  interrupt.  Each  8  ms  the  critical  radar  data  is  processed. 

A  variety  of  other  functions  are  processed  at  slower  periodic  rates, 
which  the  executive  schedules  when  all  8  ms  radar  processing  is  complete. 
An  overview  of  this  architectural  structure  is  shown  in  Fig.  5-4. 
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Fig.  5-2  CSDC  Block  Diagram 
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Modules  versus  Tactical  Routines  (from  Hughes) 
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Recovery  from  computer  program  aborts  can  be  done  by  reinitial¬ 
ization  of  the  computer  program  and  by  reload  from  the  magnetic  tape. 
Since  24k  of  the  32k  memory  is  NDRO,  only  the  8k  memory  must  be  reloaded. 
Although  there  is  only  one  computer  involved  in  the  AWG-9  system,  a 
major  hardware  failure  within  the  computer  system  is  required  to  abort 
the  mission.  Replacement  of  the  computer  modules  is  performed  on  the 
aircraft  carrier  or  on  the  land-based  site. 

5.3.2  AWG-9  Program  Functions 

The  program  functions  within  the  AWG-9  computer  are  subdivided 
into  tactical  and  BIT  as  shown  in  Fig.  5-5.  The  relative  sizes  of  each 
of  the  tactical  functions  are  illustrated  in  Fig.  5-6.  Note  that  of  the 
39k  tactical  words  (orders),  a  required  15k  are  resident  on  tape.  The 
tape  also  includes  50k  words  for  BIT.  These  functions  are  summarized  as 
follows : 


5. 3. 2.1  Tactical  Programs 
Controls  and  Displays 

Displays  Symbolic  Target  and  Ownship  Data  in  Two  Orienta¬ 
tions 

Provides  Data  Entry,  Data  Entry,  Data  Readout,  and  Mode 
Selections 

4500  Orders,  11% 

Missile 

Provides  Launch  Zone  and  Missile  larameter  Data 
2400  Orders,  6.5% 

Attack 

Assigns  Target  Priorities  and  Weighting  for  Launch  Logic 
3800  Orders,  9.5% 

Modes  Switching 

Provides  Timing  and  Logical  Changes  for  System  Modes 
500  Orders,  1.5% 

TWS  Tracking 

Correlation  of  Observations  to  Establish  and  Update  Multiple 
Target  Tracks 

3200  Orders,  8% 
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Fig.  5-5  AWG-9  Program  Module  Functions  (from  Hughes) 
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Fig.  5-6  AWG-9  Program  Module  Size  (from  Hughes) 
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STT  Tracking  and  Air-to-Ground 

Provides  Angle  and  Rate  Tracking,  A/A  Processing,  and  Gun 
Mode  Aids 

1975  Orders,  (plus  4250  on  tape),  16% 

Radar/Antenna 

Provides  Clutter  and  Acquisition  Processing 
Controls  the  Antenna  Pattern  and  Position 
3300  Orders,  8% 

Avionics 

Provides  Navigation  and  Alignment  Processing 
1350  Orders  (plus  3850  on  tape)  ,  10% 

Miscellaneous 

Instrumentation,  In-Flight -Training,  and  Data-Link  Function 
0  Orders  (plus  5000  on  tape) ,  15% 

Initialization  and  Standard  Subroutines 

Initialization  and  Power  Sequencing  ^unctions 

Bulk  Store  Transfer  and  Software  Monitoring  Processing 

2900  Orders  (plus  1900  on  tape)  ,  13% 

Executive 

Timing,  Control,  and  Interrupt  Processing 
650  Orders,  1.5% 

The  various  routines  (approximately  100)  associated  with  each  of 
tho  above  tasks  are  listed  in  Fig.  5-3. 

5. 3.2. 2  Built-In  Test  Programs 

In  addition  to  the  tactical  functions,  a  number  of  BIT  functions 
are  defined  as  follows: 

C&D 

Drives  the  C&D  with  Test  Patterns 
750  Orders,  2% 
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CP.IFU 

Exercises  the  Timing  and  Control  Functions 
Tests  the  Memories  and  Instruction  Set 
10,000  Orders,  20% 

Radar 

Performs  a  Confidence  Test  of  the  Entire  Radar  Loop 
Prompts  the  Operator  to  the  Correct  Fault  Isolation  Test 
9000  Orders,  18% 


Missile 

Determines  Missile  Readiness  Status 
7500  Orders,  15% 


Fault  Isolation 


Provides  Fault  Isolation  for  the  Following  Functions: 


Receiver: 

Transmitter: 

Antenna: 

STT  Loop: 


4250  Orders,  8% 
3500  Orders,  7% 
4500  Orders,  9% 
4500  Orders,  9% 


Special  Tests 

Special  Testing  of  Subsystem  Interfaces,  Missiles,  and  Power 
4000  Orders,  8% 


Displays  and  Executive 

Degraded  Mode  Assessment,  WRA  Display,  and  Test  Decision 
Points  for  Analysis 

2000  Orders,  4% 


The  relative  memory  usage  for  the  BIT  functions  indicated  above  is  shown 
in  Fig.  5-7. 


5.3.3  CSDC  Program  Architecture 

The  program  used  in  the  CSDC  is  a  special-purpose  program  tai¬ 
lored  for  the  F-14  functions.  The  software  system  main  driving  loop  is 
represented  by  Fig.  5-8,  which  shows  that  the  Executive  is  essentially 
distributed  throughout  the  application  program. 
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Fig.  5-7  Relative  Memory  Usage  for  AWG-9  Diagnostic  and  Test  Software 
(from  Hughes) 
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Fig.  5-8  Main  Driving  Loop  for  CSDC  Computer  Program 
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5.3.4  CSDC  Program  Functions 

The  functions  of  the  CSDC  computer  program  are  as  follows: 

1.  Tactical  Functions 

Navigation:  Primary  navigation,  including  platform  mainten¬ 

ance  . 

Converter  Functions:  Software  Controlled  multiplexing  of 
A/D,  D/A,  and  CAA  conversions. 

Controls:  Uses  or  transfers  more  than  100  discretes  and  is 
the  central  interface  for  all  avionics. 

Displays:  Interfaces  with  MDIG  and  VDIG,  supplying  all  MDIG 

avionic  inputs  and  many  of  the  VDIG  inputs. 

Data  Link:  Inputs,  decodes,  and  replies  to  the  data  link 
subsystem. 

Alignment:  Alignment  pror.edu:  a  of  the  IMU  platform. 

2.  Test  Functions 

Onboard  Checkout:  Avionics  go-no-go  indications  (includes 
continuous  self-test)  . 

5.4  SOFTWARE  DEFINITION,  DESIGN,  AND  IMPLEMENTATION 

5.4.1  AWG-9  Program  Definition 

An  overview  of  the  definition  documents  for  the  AWG-9  system  is 
shown  in  Fig.  5-9.  The  following  documents  define  the  AWG-9  system  re¬ 
quirements  and  software: 

1 ,  Contract  Specifications  (AS2195,  AS2197,  AS2206,  etc.):  A 
group  of  approximately  17  specifications  covering  AWG-9  sys¬ 
tem  performance.  There  are  no  specific  software  performance 
criteria  except  in  terms  of  system  performance.  These  docu¬ 
ments  serve  the  purpose  of  the  Computer  Program  Peformance 
Specifications ; 

2 .  HAC  Software  Design  Requirement  Drawing!?  (481CPN/B-600) :  A 
group  of  drawings  used  in  early  phases  of  development  of  the 
program  to  convey  to  the  programming  activity  the  specific 
requirement  for  developing  the  program.  These  drawings  were 
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not  updated  after  initial  design  to  reflect  system  changes. 
This  document  corresponds  to  the  Computer  Program  Design 
Specifications ; 

3 .  HAC  Software  Design  Description  Drawings  (4810CP-700) :  A 
group  of  drawings  containing  narrative  and  flow  chart  de¬ 
scriptions  of  the  various  computer  program  components,  i.e., 
routines,  subroutines,  BIT  sequences,  software  dictionary 
items,  and  standard  subroutines.  Generation  of  these  docu¬ 
ments  including  flow  chart  generation  is  fully  automated. 
These  documents  correspond  to  the  Computer  Sub-Program  De¬ 
sign  Documents.  (The  dictionary  defines  all  common  terms 
and  equations  used  throughout  the  program.  Standard  sub¬ 
routines  are  those  items  used  by  more  than  one  routine  in 
the  computer  program.); 

4.  Computer  Program  Package;  The  computer  program  package  con¬ 
sists  of  programs  on  magnetic  tapes  and  program  listings;  and 

5 .  Phoenix  XN-3  Computer  Programming  Policies  and  Procedures: 

The  document  was  initially  used  during  the  initial  develop¬ 
ment  in  1969  but  is  not  currently  maintained.  It  consisted 
of  two  sections  defining  program  development  steps  and  pro¬ 
gram  development  policies.  Included  In  the  first  section 
were  definitions  for  the  functional  design  document,  flow 
charting,  scaling,  coding,  static  simulation,  dynamic  simu¬ 
lation,  and  the  program  description  document.  Included  in 
the  second  section,  program  development  policies,  were  defi¬ 
nitions  for  tape  identification,  computer  program  routine 
all  letter  allocation,  labelling,  comments,  subroutine  call¬ 
ing  sequence,  mode  transitions,  memory  utilization,  and  sym¬ 
bology  indentation  control. 

5.4.2  AWG-9  Program  Design 

Initial  design  was  aided  by  early  developmental  work  performed 
at  the  Naval  Air  Development  Center  (NADC) ,  particularly  in  the  area  of 
track-while-scan  radar  logic.  Later  involvement  by  NADC  in  design  review 
and  interaction  also  proved  useful  in  the  design  activity. 

The  design  document  for  AWG-9  software  consists  of  a  series  of 
documents  entitled  HAC  Software  Design  Description  Drawings  (4810CP-700 
drawings) .  These  documents  went  under  MIL-STD-480  control  as  of  May 
1975.  As  an  example  of  the  level  of  detail  in  these  documents  and  the 
automatic  generation  of  text  and  flow  charts,  three  sample  pages  of  an 
18-page  document  for  the  Data  Entry  Routine  are  shown  in  Figs.  5-10 
through  5-12. 
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04/22/75  AUTOFLOW  CHART  SET  •  PHX  PAGE  02 

CHART  TITLE  DE  DATA  ENTRY  ROUTINE  (U)  3238368  RE  V  K 


PURPOSE 


(Ul  THE  PURPOSE  OF  THIS  ROUTINE  IS  TO  ENTER  DATA  INTO  THE  APPROPRIATE  LOCATION  WHENEVER  THE  NFO  ENTERS  DATA  ON  THE 
COMPUTER  ADDRESS  PANE  L  (CAPl 

FUNCTIONAL  DESCRIPTION 


INTRODUCTION  (Ul  THE  DATA  ENTRY  (DE)  ROUTINE  IS  ENTERED  FROM  THE  FUNCTION  SWITCH  (FSI  ROUTINE  DURING  THE  B  MSEC 
CYCLE  BV  PRESSING  THE  ENTER  BUTTON  ON  THE  CAP.  THE  CATEGORY  SWITCH  SETTING.  F UNCTlDN  SWITCH  SE  LECTION. 

KEYBOARD  FUNCTION  CODE  AND  THE  TYPE  OF  HOOK  PRESENTLY  IN  EFFECT  ARE  E  X  AMI  NED  TO  OETERMlNE  THE  TYPE  OF  DATA 
BEING  ENTERED  THE  DATA  IS  CONVERTED  TO  BINARY,  PROPERLY  SCALED  AND  STORED  IN  THE  APPROPRIATE  LOCATION  FOR  USE  BY 
THE  PROGRAM 

DESCRIPTION  (U)  THE  DE  ROUTINE  F IRST  CHECKS  THE  STATUS  OF  THE  KEYBOARD  FUNCTION  IF  AN  ILLEGAL  KE YBOARD  F UNCTION  IS 
ENTERED.  THE  ROUTINE  EXITS  OTHERWISE  THE  OE  ROUTINE  CALLSTHE  DIGITAL  INPUT  (Dll  ROUTINE  WHICH  CONVERTS  AND 
SCALES  THIS  INPUT  DATA 

(Ul  THE  CATEGORY  AND  KEYBOARD  FUNCTION  F  LAGS.  WHICH  ARE  SET  BY  Dl  DETERMINE  THE  LOCATIONS  WHE RE  THE  SCALED  DATA 
IS  TO  BE  STORED 

IUI  THE  DE  ROUTINE  THEN  CHECKS  IF  A  HOOK  IS  IN  EFFECT  IF  A  PSEUDO  HOOK  IS  IN  EFFECT,  LATITUDE  AND  LONGITUDE 

ARE  STORED  IN  TEMPORARY  LOCATIONS.  FROM  WHICH  CONVERSIONS  OF  THE  EAST  AND  NORTH  TARGET  RANGE  VECTOR  COMPONENTS  ARE 

MADE 

(Ul  ENTRY  OF  EITHER  LATITUDE  OR  LONGITUDE  CAUSES  CALCULATION  ANDSTDRINGOF  RANGE  INFORMATION  CONSEQUENTLY. 

THE  STORED  VALUF  OF  LATITUDE  OR  LONGITUDE  RESULTS  IN  AN  INCORRECT  CALCULATION  OF  RANGE  ANO  BEARING  UNTIL  THE  SECOND 
VALUE  IS  ENTERED 

(Ul  CALCULATION  OF  LATITUDE  AND  LONGITUDE  FROM  RANGE  AND  BEARING  IS  PERFORMED  IN  THE  SAME  MANNER  RANGE  AND  BEARING 
ARE  STORED  IN  TEMPORARY  LOCATIONS  PRIOR  TO  CONVERSION  TO  LATITUDE  AND  LONGITUDE  ENTRY  OF  EITHER  OUANTITY  CAUSES 
CALCULATION  AND  STORING  OF  LATITUDE  AND  LONGITUDE  CONSEQUENTLY,  THE  STDRED  VALUE  OF  RANGE  OR  BEARING  WILL 
USUALLY  RESULT  IN  AN  INCORRECT  CALCULATION  OF  LATITUDE  AND  LONGITUDE  UNTIL  THE  SECOND  VALUE  IS  ENTERED 

(U)  FOR  PSEUDO  FILES.  THE  TARGET  X  ANO  Y  COORDINATES  ARE  ALSO  CALCULATED  WHENEVER  R ANGE ,  BE AR ING.  LATITUDE, OR 
LONGITUDE  IS  ENTERED 

(U)  WHEN  HEADING.  SPEED,  DR  RANGE  IS  ENTEREO  INTO  ASENSOR  FILE. IT  IS  STORED  INTO  THE  APPROPRIATE  LOCATION  AND  RANGE 
RATE  VALID  ISRESET  AND  THE  ASPECT  ANGLE  FILTER  IS  INITIALIZED  ALSD.WHEN  RANGE  IS  ENTERED  THE  KALMAN  FILTER 
IS  INITIALIZED 

(U)  IN  THE  NAV  CATEGORY.  WHEN  THE  OWN  A/C  FLAG  IS  ON.  THE  DE  ROUTINE  STORES  ENTRIES  OF  LATITUDE.  LONGITUDE,  HEADING. 


Fig.  5-10  Autoflow  Chart  Set,  Data  Entry  Routine,  Page  2 
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AND  ALTITUDE  OF  OWN  A  C  INTO  LOCATIONS  OUTSIOE  THE  1  RACK 
FILE  FOR  USE  BY  THE  NAVIGATION  ROUTINE 

(Ul  WHEN  THE  NAVIGATION  SYSTEM  IS  IN  AN  ALIGNMENT  MODE.  HEADING.  COURSE  AND  BEARING  ARE  TRUE  NORTH  REFERENCED 
OTHERWISE.  THEY  ARE  MAGNETIC  NORTH  REFERENCED  AND  THE  MAGNETIC  VARIATION  IS  ADDEOTO  THE  KEYBOARD  VALUE  8EFORE 
DE  STORESTHE  ENTRY 

IUI  THE  ATTACHED  TABLE  NO  1  SPECIFIES  THE  OATA  ENTRIES  ALLOWED  AND  DATA  READOUTS  E  XPFCTE D  BASED  ON  TYPE  OF  HOOK 
IN  EFFECT 


Fig.  5-11 


Autoflow  Chart  Set,  Data  Entry  Routine,  Page  3 
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Fig.  5-12  Autoflow  Chart  Set,  Data  Entry  Routine,  Page  6 
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5.4.3  AWG-9  Program  Implementation 

Figure  5-13  illustrates  the  development  cycle  used  in  software 
generation  for  the  AWG-9  system.  In  particular,  the  tasks  required  for 
computer  programming  are  illustrated  in  Fig.  5-14. 


5. 4. 3.1  Initial  Development 


Since  the  software  for  the  AWG-9  was  developed  prior  to  an  avail¬ 
able  system  to  exercise  the  computer  system,  extensive  use  of  simulation 
was  required  in  program  development.  Figure  5-15  illustrates  the  com¬ 
puter-based  systems  for  computer  program  development.  Prior  to  opera¬ 
tional  program  coding,  extensive  parametric  analysis  was  performed,  which 
formed  the  basis  for  simulations  later  used  in  performance  evaluation. 
Simulations  were  performed  for  such  functions  as  track-while-scan,  ve¬ 
locity  loop,  angle  tracking  loop,  low  PRF  range  tracker,  and  F-14  real¬ 
time  steering. 


The  Metaplan  language  was  selected  in  1965  as  the  language  for 
use  in  the  AWG-9  Weapon  System.  At  the  time,  there  was  no  standard  or 
convenient  high-level  language  available  for  avionic  systems.  An  ini¬ 
tial  requirement  was  for  machine  independence  so  that  programs  could  be 
developed  prior  to  the  selection  of  the  computer  to  be  used  for  the  sys¬ 
tem.  Metaplan  was  originally  a  systems  implementation  language  devel¬ 
oped  for  use  in  writing  operating  systems  programs.  The  compiler  for 
the  AWG-9  system  was  developed  by  a  subcontractor  to  Hughes  Aircraft  and 
later  development  and  maintenance  was  continued  by  Hughes.  One  of  the 
prime  goals  in  the  design  of  the  compiler  was  efficiency  of  code  gener¬ 
ation,  which  was  required  by  avionics  programs.  In  three  benchmark  pro¬ 
grams,  an  efficiency  of  between  90  and  95%  of  an  assembly  language  pro¬ 
gram  was  demonstrated.  An  assembler  is  also  available  for  the  AWG-9 
computer  that  can  be  used  for  code  segments  that  must  be  extremely  effi 
cient . 


5.4.4  CSDC  Program  Definition 


Since  the  CSDC  software  program  is  only  a  small  part  of  the  sys¬ 
tem  as  compared  to  the  total  F-14  aircraft,  Grumman  has  not  invested  a 
great  deal  of  effort  in  the  software  definition.  It  appears  to  have 
been  a  one-man  effort  based  on  a  general  outline  of  the  functions  to  be 
performed  by  the  computer.  (Note:  the  major  software  effort  in  the 
F-14  program  is  tied  up  with  the  AWG-9  Weapon  System.) 
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5.4.5  CSDC  Program  Design  Documents 

The  following  documents  contain  a  description  of  the  program  de¬ 
sign  for  the  purpose  of  system  maintenance  and  operational  training  and 
procedures.  However,  they  do  not  discuss  the  methods  used  to  design 
the  program  itself. 

1.  Technical  Manual  Organizational  Maintenance  Integrated 
Weapon  System  Functional  Diagrams;  NAVAIR01-F14AAA2-2-16. 

2.  Navy  Aviation  Training  and  Operational  Procedures  Standards 
(NATOPS) . 

5.4.6  CSDC  Program  Implementation 

No  formal  procedures  were  followed  in  implementing  individual 
software  modules  (see  Section  5.4.4).  However,  all  software  was  thor¬ 
oughly  tested  on  the  total  system  level  in  the  System  Integration  Test 
Site  (SITS)  (see  Section  5.5.3). 


5.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

Operational  F-14/Phoenix  programs  are  tested  at  the  total  system 
(hardware  and  software)  level.  Programs  are  run  in  real  time  in  an  AWG- 
9 /CSDC  computer  system  that  is  interfaced  with  the  radar,  display,  and 
missile  interface  subsystem.  Test  results  are  measured  against  a  base¬ 
line  or  increased  system  performance  models  depending  on  specific  changes. 
Within  Hughes  Aircraft  Company  (HAC) ,  test  and  validation  is  performed 
at  the  system  engineering  and  flight  test  levels.  Validated  programs  are 
then  delivered  to  the  Navy  and  Grumman  Aerospace  Corporation  (GAC)  for 
system  validation  before  deployment  in  the  Fleet. 

5.5.1  AWG-9/HAC  Test  and  Validation 

Validation  tools  in  use  by  HAC  include  a  Sigma-5  based  simula¬ 
tion  system  as  depicted  in  Fig.  5-16,  and  various  roofhouse  and  flight 
test  tools.  The  roofhouse  at  HAC  Includes  two  AWG— 9  systems  into  which 
a  number  of  simulated  inputs  can  be  made  including  a  moving  target  simu¬ 
lator,  an  IF  radar  target  simulator,  and  an  ECM  pod.  Aircraft  flyovers 
are  also  used  in  the  software  validation.  Computer  support  equipment  is 
available  for  detailed  program  analysis  and  debugging.  Equipment  used 
during  HAC  flignt  tests  at  the  Pacific  Missile  Range  include  two  bailed 
aircraft  (TA3-B ,  F-14) ,  targets  supplied  by  PMR,  missiles  for  captive 
carry,  and  missiles  for  launch.  During  all  tests,  data  recordings  can 
be  made  on  magnetic  tape  of  intermediate  and  interface  variables.  The 
Hughes  Phoenix  roofhouse  offers  a  unique  and  diversified  resource  for 
development  of  the  AWG-9  software.  In  the  roofhouse,  the  software  is 
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Fig.  5-16  Validation  of  AWG-9  Tactical  Programs 
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combined  with  the  AWG-9  hardware,  including  an  AIM-54  missile,  to  form 
the  total  AWG-9  hardware,  including  an  AIM-54  missile,  to  form  the  total 
AWG-9  system.  This  combination  of  the  hardware  and  software  plus  the 
totality  of  target /hardware/missile  simulators  and  instrumentation/re¬ 
cording  equipment  makes  the  roofhouse  an  invaluable  resource  for  two 
vital  phases  of  software  development,  software  checkout,  and  software 
verification/ evaluation . 

The  roofhouse  checkout  phase  of  software  development  deals  with 
individual  software  changes.  The  roofhouse  with  its  available  equipment 
thus  allows  the  software  engineer  to  determine  if  a  particular  software 
change  has  been  implemented  correctly  and  if  it  accomplishes  the  desired 
function  without  impacting  other  software  in  a  detrimental  manner. 

The  software  verification/evaluation  phase  of  software  develop¬ 
ment  ascertains  the  overall  performance  of  the  complete  software  pack¬ 
age  with  regard  to  system  design  requirements,  performance  specifica¬ 
tions,  system  threats/missions,  and  agreements  between  the  customer 
and  contractor.  This  phase  is  accomplished  by  the  software  test  engi¬ 
neer  designing  tests  for  the  above  mentioned  conditions  and  then  either 
using  the  various  simulators  to  input  the  required  signals  or  using  the 
roofhouse  capability  of  having  real  targets  fly  against  the  system.  The 
roofhouse  is  an  ideal  source  for  the  performance  of  these  tests  since 
the  instrumentation/recording  equipment  it  contains  allows  the  software 
test  engineer  to  capture  quickly  all  necessary  information. 

With  use  of  PMR  radars  and  missile  range  computers,  AWG-9  data 
and  ground  data  are  merged  to  develop  accuracy  data  used  in  determining 
acceptability.  The  decision  for  a  formal  tape  release  of  an  AWG-9  pro¬ 
gram  is  made  at  a  formal  management  review  in  which  HAC  System  Engineer¬ 
ing  presents  the  results  of  verification  testing.  Results  include  test¬ 
ing  accomplished,  planned  testing,  tests  to  be  accomplished,  performance 
demonstrated,  and  problems  to  be  fixed.  When  a  "release"  decision  is 
made,  the  tape  and  documentation  are  delivered  to  the  Navy  Software 
Support  Activity  (SSA)  for  tests. 

5.5.2  CSDC/Grnmman  Test  and  Validation 

Since  program  changes  in  the  CSDC  computer  are  generally  highly 
visible,  Grumman' s  approach  to  validation  and  testing  of  development 
software  relies  on  use  of  the  SITS  (a  Grumman  developed  test  tool)  as 
depicted  in  Fig.  5-17.  Validation  of  Grumman-developed  AWG-9  computer 
resident  programs  proceeds  generally  as  outlined  in  the  previous  section. 

5.5.3  F-14  System  Test  and  Validation 

Further  testing  on  delivered  programs  was  performed  at  PMR  Pt. 
Mugu  by  Grumman  in  the  SITS.  Figure  5-18  illustrates  the  components  of 
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Fig.  5-17  SITS  Testing  of  Development  Software 
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the  test  site  when  used  to  test  production  software.  SITS  is  a  Grumman- 
developed  software  development  tool  that  includes  a  replica  of  the  F-14A 
forward  module  housing  all  weapon  system  hardware.  It  has  now  been 
transitioned  to  the  Navy  SSA.  An  associated  computer  complex  provides 
controlled  inputs  of  synthetic  targets  and  dynamic  simulation  of  flight 
parameters.  SITS  provides  step-by-step  buildup,  integration,  and  eval¬ 
uation  of  weapon  system  hardware  and  software  while  permitting  full 
crew  participation.  SITS  supporting  facilities  permit  acquisition  of 
desired  performance  data  and  data  reduction  for  subsequent  system  analy¬ 
sis.  The  test  site  is  used  by  the  SSA  to  evaluate  and  verify  tactical 
tapes  before  delivery  to  the  Fleet.  It  is  also  used  to  evaluate  and 
verify  hardware  changes  to  weapon  systems  before  production  and/or  Fleet 
incorporation. 

In  addition  to  its  use  in  test  and  validation,  the  test  site 
provided  a  significant  contribution  in  the  test  of  the  Link  4A  two-way 
data  link.  Since  the  F-14  is  the  only  aircraft  with  a  two-way  Link  4A, 
the  system  for  testing  the  Link  4A  hardware  had  not  been  developed.  A 
Sigma-3  computer  was  used  to  control  a  Link  4A  transmitter  for  simula¬ 
tion  of  a  participating  unit.  F-14  hardware  was  then  tested  with  the 
simulator Later  the  Link  4A  was  tested  with  NTDS  using  FCDSSA  programs 
at  PMR  and  the  F-14  at  the  test  site.  Compatibility  with  NTDS  was  es¬ 
tablished  in  about  1972.  Later  integration  of  the  E-2C  to  provide  F-14 
to  E-2C  two-way  communication  was  tested. 


5.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 

5.6.1  HAC  Management  Organization 

The  software  management  organization  at  HAC  and  its  relation  to 
other  agencies  is  shown  in  Fig.  5-19. 

5.6.2  HAC  Personnel  Management 

The  AWG-9  software  management  process  uses  a  "module"  concept; 
that  is,  the  software  is  divided  into  several  functional  modules  to 
which  teams  of  specialists  are  assigned.  The  module  teams  are  under  the 
direction  of  the  AWG-9  System  Engineering  Department.  Each  team  is  made 
up  of  people  from  system  engineering  (both  system  design  and  system 
evaluation),  syotem  analysis,  programming,  and  flight  test.  Each  team 
is  responsible  for  its  assigned  module  from  inception  through  Fleet  de¬ 
ployment.  The  three  tactical  software  modules  are  the  track-while-scan 
(TWS)  group,  single-target- track  (STT)  group,  and  weapons  group;  the  two 
BIT  software  modules  are  the  radar  group  and  processing  group.  The  five 
teams  are  shown  in  Fig.  5-20. 

The  module  approach  to  developing  the  AWG-9  software  has  resulted 
in  efficient  software  generation,  since  many  problems  are  found  at  the 
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Fig,  5-19  HAC  Software  Management  Organization 
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paperwork  level,  and  their  discovery  and  resolution  are  not  delayed  un¬ 
til  the  tape  is  in  use  in  a  system  laboratory,  in  flight  test,  or  in  ac¬ 
tual  Fleet  deployment.  Also,  the  software  system  engineering  designer 
and  the  programmer  are  available  during  evaluation,  both  in  the  AWG-9 
roofhouse  and  in  flight  test,  to  provide  the  needed  insights  for  quick 
resolution  of  system  operational  problems. 

5.6.3  Management  Documents 

The  following  documents  are  relevant  to  the  F-14  software  devel¬ 
opment  : 

Specifications 

System  Specification  —  F-14A  Armament  System  (AS-2195) 

F-14A  Weapon  Control  System  (AS-2197) 

Detailed  Specification  —  AWG-9  Computer  Software  (AS-2206) 

Interface  Specifications  —  F-14A  Weapon  Control  System  In¬ 
terface  with  the  AIM-7E  Guided  Missile  (AS-2187C) 

F-14A  Weapon  Control  System  -  Interface  with  the  AIM-9G 
(AS-2188C) 

F-14A  Weapon  Control  System  Interface  with  the  AIM-9G/H 
(AS-3735) 

F-14A  Weapon  Control  System  Interface  with  F-14A  Avionics 
(AS-2189C) 

F-14A  Weapon  Control  System  Installation  and  Physical  Inter¬ 
face  with  F-14A  Aircraft  (AS-2191C) 

F-14A  Weapon  Control  System  Interface  with  AIM-7F-4  Guided 
Missile  (AS-2194C) 

AN/ AWG-9  (N-3)  Interface  with  the  AIM-54-1  Missile  (AS-2695) 

Miscellaneous 

Master  Index,  Phoenix  F-14A  AN/AWG-9  Software  (MI  4810CP-100) 

Software  Indentured  Drawing  Lists  and  Software  Design  De¬ 
scriptions  (4810CP-7XX) 

Program  Listings  (4810CP-3XX) 

Agreement  of  Responsibilities  Between  Grumman  and  Hughes 
(8  Jan  1969) 

Phoenix/F-l4A  Software  Agreement  Between  Grumman  and  Hughes 
(9  Jun  1969) 
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Phoenix/F-14A  Software  Configuration  Control  Agreement  Be¬ 
tween  Hughes  and  Grumman  (13  Oct  1970) 

Baseline  Software  Release  Ground  Rules  by  NAVMISCEN/Hughes 
and  Grumman  (Tape  111  Ground  Rules,  24  Mar  1975) 

5.6.4  HAC  Management  Techniques 

The  basic  contractual  requirement  for  the  AWG-9  system  was  to 
design  to  a  level  of  performance.  Government-imposed  requirements  in¬ 
cluded  the  F-14  Software  Management  Plan  (NAVAIR  PMS  241-VM/SDN  SER 
75-27  (7  Feb  1975)),  and  General  Purpose,  Programmable  Airborne  Digital 
Computer  Systems  Program  Data,  General  Requirements  for  AR-15  (20  Sept 
1967).  In  addition  to  Government-imposed  requirements,  design  audit 
and  review  are  performed  through  the  Navy  NTE  and  NPE  and  the  Navy  BIS. 
AWG-9  computer  programs  went  under  MIL-STD-480  product  baseline  config¬ 
uration  control  on  2  May  1975.  Test  and  validation  as  described  in  the 
previous  section  also  served  as  a  management  technique. 

5.6.5  HAC  Management  Findings 

Hughes  strongly  believes  that  the  use  of  a  programming  subcon¬ 
tractor  in  software  development  for  avionic  systems  is  counter-produc¬ 
tive.  They  state  the  position  that  software  development  is  integral  to 
the  system  design  process,  and  the  system  design  cannot  be  developed  on 
paper  to  the  extent  that  a  programmer  can  develop  an  acceptable  product. 
Also,  coding  is  a  trivial  part  of  the  overall  job  of  software  develop¬ 
ment  . 

5.6.6  GAC  Management 

Management  of  the  Grumman  effort  is  concentrated  at  the  total 
system  (aircraft)  level,  software  being  a  rather  insignificant  part  of 
the  whole.  No  formal  management  strucure  could  be  identified  in  connec¬ 
tion  with  the  software  (CSDC)  effort. 


5.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

The  ultimate  responsibility  for  operational  software  maintenance 
of  the  AWG-9 /CSDC  programs  will  be  assigned  to  the  Navy  SSA  as  estab¬ 
lished  by  NAVAIR  through  the  Software  Management  Plan.  Figure  5-21  is 
«  a  block  diagram  showing  the  Navy  organization.  The  SSA  (at  PMTS)  has 
recently  taken  over  configuration  management  of  the  AWG-9  computer  pro-» 
gram  (an  organizational  setup  is  shown  in  Fig.  5-22)  and  is  developing 
documentation  and  compiler  support  in  preparation  for  assuming  mainten¬ 
ance  responsibility.  It  is  expected  that  significant  new  support  for 
software  maintenance  will  be  required  because  of  the  highly  technical 
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5.8  HIGHLIGHTS 

An  AWG-9  design  approach  based  on  expanded  software  interaction 

and  control  of  system  hardware  functions  Permitted^  j^P1^*  software 

velopment  cylce.  The  system  ^venent  without 

has  permitted  AWG-9  system  growth  and  funct  (MP1.SE1.SE2) 

hardware  modification  to  in-service  systems. 

fioviMHtv  and  growth  potential  was  designed  into  the 

AWG-9  computer  interface  hardware  to  permit iintegration^of^devices^^er^ 

a  variety  of  interface  typ  analog  interfaces  pro¬ 
face  capability  for  parallel,  seria  ,  ,  (MP1.SE1.SE2) 

vides  this  capability. 

.,  ,,,,,  Mm.  that  the  AWG-9  was  developed,  NDRO  memory  provided 
the  speed  aud  security  regulred 

for  new  systems.  («» 

The  Metaplan  compiler  was  developed  for  the  AWG-9  to  provide  a 
]h,  jP  ..  M  ph-level  language  with  a  stringent  requirement 
machine-independent,  high  RPnrhmark  tests  indicate  an  effi- 

for  efficiency  of  generated  code.  Benchmark  tests  (SE3,IP1) 

ciency  level  of  90  to  95%  has  been  achieved. 

The  establishment  of  the  SITS  by  Grumman  permitted  extensivef 

testing  and  validation  of  the  chus  obtained  in  the 

flight  testing.  *8reateal  iocation  of  SITS  at  a  government  in- 

££££*(£.: :£pthS ^  dances  th.  transferability  of  the  system^ 
software  to  the  Navy  SSA. 

iL^sriTzz 

an^at 1  theS Grumman  SITS  to.te^“t*a^y  <£“£  two-way'"!'^ 

PMR.  SITS  also  provided  tnc  facility  for  t  (IP3) 

tests . 
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